6年ぶりぐらいにクラウド使った結果、Kubernetes以外のマネージドサービスとか基本要らなくない？となった話 - データエンジニアの酩酊日記
ここ半年ぐらい、かなり久々にクラウド使ってアプリやバッチの基盤作ったりしてきて、色々と思ったことを書き捨てる。 「ちょっと検証してみた」程度のものも含めれば、AWSとGCPは一通り主要なマネージドサービスを触ったし、実際に複数のアプリやらバッチやらをマネージドサービス上で本番稼働させて今も運用してるけど、結局DB以外は基本全部Kubernetesに乗せるのが一番楽だと強く思うようになった。 Kubernetesは学習コストや運用コストがそれなりに高く付くから安易に採用するのはどうなのか、みたいな論調もあるし、つい半年前までは自分もそう思ってた。サーバレスなマネージドサービスが色々出てきているのに、なんでわざわざKubernetesクラスタなんていう設計、運用に手間のかかるクラスタリングサーバーを立てて管理しないとならんのかと。 だけど、実際にいくつかのマネージドサービス使ってアプリやバッチ
まだTerraform使ってるの？未来はPulumiだよ
Lv：4 Exp：19011 プログラマー友の中釣りが一番上手、釣友の中インフラが一番得意、インフラ友の中猫が一番好き、猫友の中プログラミングが一番詳しい。 本当のInfrastructure as Codeを実現するPulumi インフラをコードにして管理する、所謂Infrastructure as Code(IaC)、特にクラウド上のインフラ管理はTerraformというツールがよく使われていると思います。クラウドエースでもインフラ管理にはTerraformを使用しています。しかし、このInfrastructure as Codeは本当のCodeではなく、Configurationです。今回は本当のInfrastructure as Codeを実践するPulumiというツールを紹介したいと思います。 Pulumiはまさにプログラミングでインフラを自動化する Pulumiは自分が好きなプ
国内IaaS／PaaS市場、止まらぬ拡大 22年度には計1兆円超えへ
調査会社のアイ・ティー・アールが、国内のIaaS／PaaS市場規模と今後の予測を発表。2017年度現在、両市場の規模は前年度比34.1％増となる計3575億5000万円。その後も引き続き拡大し、22年度には計1兆1066億円に上る見込みとしている。 調査会社のアイ・ティ・アールはこのほど、国内のIaaS／PaaS市場規模と今後の予測を発表した。2017年度現在、両市場の規模は前年度比34.1％増となる計3575億5000万円で、上位企業を中心にほぼ全てのベンダーが順調に売り上げを伸ばしたという。市場規模は引き続き拡大し、22年度には計1兆1066億円に上る見込みとしている。 IaaS市場は5年間で約2倍に 個別にみると、17年度現在のIaaS市場規模は2529億円。今後は、18年度は3225億円、19年度は4002億円、20年度は4823億円、21年度は5339億円、22年度は5763億円
10年モノのインフラを3年がかりでカイゼンした - Qiita
CI いちおうJenkinsが立ってました。失敗して赤くなってるジョブが大半で、かといって誰が治すわけでもなく、よくわからないけど失敗したり成功したり、とにかく不安定でした。 CloudWatchのメトリクスで眺めて、EBSのIOPSクレジットの枯渇から激遅になって、Jenkinsジョブのタイムアウト設定で失敗になる、まで明らかにしました。その時の対処は、IOPSクレジット上限サイズの1TBのSSDのEBSを付けることと、同時並行で動けるJenkinsジョブ数に上限を設けることで、落ち着くようになりました。 とはいえ「Jenkinsおじさん」問題があるので、CIをどうにか民主化する必要があります。SaaSから検討して、TravisCIとCircleCIが最終候補になって、トラブルシュートをSSHでできるのを決め手に、CircleCIを導入しました。 8月末にCircleCI1.0が死んだと
IaaSをいじっている人が PaaSについて考えたこと / Should We Prepare Own PaaS?
OpenStackによる自社IaaSを構築・運用しているメンバーがOSSによる自社PaaSを準備するかどうか検討してみました
インフラエンジニアの独り言、ストレージは盲点になりがち - orangeitems’s diary
インフラエンジニアの世界 IT技術者というと世間から見たら、要件定義やシステム設計をおこなうシステムエンジニアと、それを実装するプログラマーしか見えてないと思うんですよね。でもその基盤を動かすインフラエンジニアという人たちが全体の10パーセント弱（肌感）存在しています。 インフラエンジニアと言ってもまたそこから役割分担があって、物理サーバーやOSに強いサーバーエンジニアと、ネットワークに強いネットワークエンジニアがいます。大昔は物理サーバーとネットワークしかインフラに無かったので、大体はこの二極化でした。ネットワークエンジニアはスイッチやファイアウォール、ロードバランサーくらいまでは自分の領域としてくれていますが、OSやミドルウェアのことになると、それは私の領域ではない発言が出てサーバーエンジニアをブチ切れさせること請け合い。逆にネットワークエンジニアはサーバーエンジニアがなんでもネットワ
【参考訳】Terraform 導入の推奨手順（Recommended Practices） ‣ Pocketstudio.Net
Terraform Recommended Practices 推奨手順 「Terraformって何がいいんですか？」と訊かれる度に答えていた内容が、とても良い感じにまとまっていましたので、ここで紹介します。2017年11月28日現在の Terraform Recommended Practices の参考訳です。 自動化や運用に興味がある方にとって参考となるのは、HashiCorp の Terraform に興味が無くても、成熟度に応じた自動化の段階分けと、各々の段階からどのように発展すべきかという手順です。手動→半自動→インフラのコード化（Infrastructure as Code）への進歩と、最終的には協調的インフラのコード化（Collaborative Infrastructure as Code）を目指して、バージョン管理や構成管理ツールと連携するにはどうしたらよいのか。あるい
アプリケーションエンジニアのためのOpenStackライブラリ「oslo.messaging」徹底解説
本稿は、アプリケーションエンジニアのためのOpenStackの記事です。ここでの内容によって、皆さんが携わるアプリケーションのサステナビリティ（Sustainability）の向上に寄与できると考えています。OpenStackはIaaSクラウド機能を提供するOSSとして知られていますが、普段アプリケーションの開発を行うエンジニアにとってはレイヤの違いから縁遠い存在に思えるかもしれません。本稿ではそうしたアプリケーションエンジニアが活用できるOpenStackプロジェクト「oslo」についての紹介と、RPCと通知機能を提供するライブラリ「oslo.messaging」の機能と使い方について徹底解説していきます。 また、OpenStack自体について興味がある方は『マイクロサービスアーキテクチャが支えるOpenStackの動作と仕組み』の連載記事も併せてご参照ください。 osloとは？ osl
KubernetesとOpenStackを連携させる方法
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog OpenStackの運用エンジニアをしている木下です。 今回はマルチプラットフォームCI環境に関する連載の第4弾として、KubernetesとOpenStackの連携を検証した際に分かった、動作させる手順と現在の状況について説明していきたいと思います。 本エントリーでは、「Kubernetesの認証としてKeystoneを利用する方法」、「KubernetesからCinderを利用する方法」の2つを詳しく解説していきます。 本エントリーで検証したKubernetesのバージョンは1.2.2になります。 Kubernetesの認証としてKeystoneを利用する Kubernetesの認証・認可の機構に関して簡単に説明したあと、Ke
ガートナーがIaaSクラウド市場のマジッククアドラント2016年版を発表。Amazonクラウドの圧倒的リーダーは変わらず
ガートナーがIaaSクラウド市場のマジッククアドラント2016年版を発表。Amazonクラウドの圧倒的リーダーは変わらず 米調査会社のガートナーは、Iaas市場におけるベンダの特徴を示した2016年版のマジッククアドラント「Magic Quadrant for Cloud Infrastructure as a Service, Worldwide」を公開しました。 マジッククアドラントでは、右上に位置づけられるベンダほど市場に対応する成熟した製品を提供しており、市場の方向性にも影響を及ぼすリーダーであるとされます。右下はビジョナリーとして概念は先行するが能力が実証されていない傾向があり、左下は特定市場を指向したニッチなプレイヤーの傾向があるとされています。 2016年版でもAmazonクラウドが他社を大きく引き離した圧倒的なリーダーの位置にあり、マイクロソフトが2番手につけている構図は昨
Google、インテル、Mirantisが、DockerとKubernetesの上でOpenStackを動かすプロジェクト始動。つまり、だいたいどんなクラウドでもOpenStackが動くようになる
Googleとインテル、そしてMirantisの3社は、協力してDockerとKubernetesを基盤に、その上でOpenStackを動かすためのプロジェクトを開始すると発表しました。 OpenStackの上でDockerやKubernetesを動かすのではありません。それはOpenStackを構成するMagnumという機能で実現されています。 そうではなく、DockerとKubernetesの上で、クラウド基盤ソフトウェアであるOpenStackを動かそうとしているのです。 もしこれが実現すれば、だいたいどんなクラウドでもDockerは動きますしKubernetesも動きますから、だいたいどんなクラウドでもOpenStackが動くようになる、ということになるはずです。 Mirantisの発表 Mirantis, Intel, Google Collaborate: OpenStack
AWSの複雑な仕組みをTerraform化で紐解く事例 | 外道父の匠
インフラエンジニアも、そうでないエンジニアも、程度の差こそあれAWS（パブリッククラウド）の知識は欠かせないものになりつつあります。しかしながら、食わず嫌いだけならまだしも、AWSにそこそこ取り組み続けているのに、しばしば嫌気がさすことすらあるのは、AWSの複雑さが原因の１つであるといっていいでしょう。 今回は、そんな複雑な仕組みの一つを、Terraform用にコード化することでココロのスキマ、お埋めします。 Infrastructure as Code の過程 Infrastructure as Code によって、手動管理をやめて自動化することのメリットは言うまでもないですが、今回は自動化する過程にこそ非常に大きなメリットがある、という視点にスポットを当てていきます。 AWSは多機能で便利であるがゆえに、複雑です。そして、複雑であるがゆえに、お客さんに簡単に扱ってもらえるよう、操作が簡
OpenStack「Neutron」のコアレビューアに、NTTの市原氏
「OpenStack Summitで“君が市原か”と、知らない人にも声を掛けられるようになった」。こう語るのはNTT ソフトウェアイノベーションセンタ（SIC） 第三推進プロジェクトの市原裕史氏だ。市原氏はOpenStack「Neutron」プロジェクトのコアレビューア（Core Reviewer）の一人。コアレビューアは、一般開発者が提案したパッチや新機能に対する承認権を持つ。2016年4月の選出から2カ月たち、OpenStackの発展に直接貢献できるコアレビューアの活動に、手応えを感じつつあるという。 OpenStackはオープンソースのIaaS（インフラストラクチャー・アズ・ア・サービス）構築ソフトで、コンピュート（Nova）や認証（Keystone）など、プロジェクト単位でサービスを開発する。 Neutronは、マルチテナント環境で仮想ネットワークを実現するプロジェクト。最新版への
「OpenStackのようなインフラソフトウェアは死んだ」、MirantisとRackspaceのマーケティング担当がブログで激論
「OpenStackのようなインフラソフトウェアは死んだ」、MirantisとRackspaceのマーケティング担当がブログで激論 「気がつくのに時間が掛かったかかったけれど、いまは確信している。インフラソフトウェアは死んだ」。OpenStackの専業SIerとして知られるMirantisの共同創業者でチーフマーケティングオフィサーのBoris Renski氏は、6月15日付のブログ「Infrastructure Software is Dead」をこのような書き出しで始めました。 このMirantisのブログは、Rackspaceからの反応を引き起こしています。OpenStack関係者のなかで存在感の大きな2社がいま、OpenStackのビジネスについてどう考えているのかが浮き彫りになっているので、2社のやりとりを簡単に紹介しましょう。 Mirantis：インフラソフトウェアは死んだ！
Microsoft Azureで負荷試験を行った際に引っかかったこと | 俺的備忘録 〜なんかいろいろ〜
Microsoft Azureに構築した環境で負荷試験を行った際、インフラ回りでひっかかったことについて念のため記述しておく。 一応、サポートから正式に回答いただいた(電話で聞いたとき聞き間違いかな？と思ったのでメールで詳細についてももらって確認している)ことなので、事実…ではあるようだ。 なお、この情報は2016年06月時点のものなので、仕様が変更される可能性もある。 設計前に一度MSに問い合わせたほうが良いだろう。 OS側で要求するIOPSがディスクの制限値を上回ると、ディスクの応答を数秒間停止させる …らしい。 規定のIOPS(プレミアムストレージ以外だと500が上限)を上回るIOPSが発生した場合、他の利用者に影響が出ないようAzure側でディスクが応答しないようにして調整するらしい(動作的には、ディスクが満杯になった際の挙動と同じらしい)。 で、止まってる間も規定値を超えるIOP
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
An Experiment with Gnocchi - (the Database) - Part 2 | SUSE Communities
Cloud Foundry full-stack monitoring now generally available
SUSE OpenStack Cloud 8 New Capabilities Update
An Experiment with Gnocchi - (the Database) - Part 1 | SUSE Communities
Complete walk thru deploying BOSH using BUCC - Stark & Wayne