Kubernetesをスムーズに導入するEvil Martians特製Kubernetesツールキット（翻訳）

Kubernetesをスムーズに導入するEvil Martians特製Kubernetesツールキット（翻訳）

私たちはKubernetesが「使いもの」になる前からKubernetesを使い続けていますが、2023年の時点ではまだ活用の余地があると考えています。実際Kubernetesは、HerokuやFly.ioなどのサービスが大きく育ちすぎた後のDockerコンテナ（あるいはコンテナ一般）をオーケストレーションするベストの（かつ基本的に唯一の「大規模」な）ソリューションです。大胆な主張ですが、私たちが長年培ってきたSREとしての経験によって裏付けられている信念です。

本記事ではこの点をさらに詳しく解説するとともに、私たちが既に実地で利用し、クライアント向けにサポートしているKubernetesツールキットを紹介します。このツールによって、Kubernetesの複雑さをまとめて解消し、Kubernetesのメリットを前面に押し出します。

本記事は特定の読者を念頭に置いて書かれています。すなわち、CTO、エンジニアリング担当副社長、シニアエンジニア、リードエンジニアなど、プロジェクトのインフラストラクチャやプラットフォームに関する決定を下せる立場にある人々を対象に、顧客が手軽かつ手頃な価格でKubernetesを導入できるようにし、頭痛の種になりかねなかったKubernetesを、さまざまな事例に応用可能な単なるツールの1つとしてツールボックスに収めるために私たちが行ってきた多大な取り組みを共有いたします。ぜひお付き合いください！

本記事では、プロジェクトをKubernetesに移行する価値があるかどうかを判断するクイックスタートガイドも紹介しています。

（次回記事では、さらにツールキットの技術仕様についても詳しく解説します）

Kubernetesを使う理由

私たちは、Kubernetesを最初のフルバージョンリリース前から使い倒しているチームとして、Kubernetesが最も進んだコンテナオーケストレーションソリューションであることを知っています。Kubernetesには広大なエコシステムがあり、膨大なエッジケースを柔軟にカバーできます。

私たちが創業当時から積み上げてきたSRE経験を元にお話しいたします。

• AWS CloudFormationで管理されているAW ECSを運用している複数の顧客が、アーキテクチャのカスタム変更を必要としていたことがあります。
  あのときKubernetesが使われていれば、変更導入の費用を数万ドル節約して、優秀なトータルインフラストラクチャと起動監視をずっと短期間で利用可能にできたことでしょう。
  詳しくは後述します。

• さらに、エンタープライズ規模のアプリをプレビュー用に20〜30個同時実行している顧客をいくつもお見かけしたことがあります。
  適切なKubernetesセットアップがあれば、同じことをずっと安価かつシームレスに行えます。

• あるプロダクトで、特定時間帯のピークタイムと負荷変動が発生したことがあります（これは実際に私たちが見たケースです）。
  Kubernetesがこうした状況（あるいはその他多くの状況）に対して提供しているソリューションははるかに柔軟に構成可能（かつ多くの場合安価）なので、あのときKubernetesツールキットがあれば移行はずっと簡単だったことでしょう。当時の選択肢にKubernetesしかなかったわけではありませんが、Kubernetesへの移行は顧客にとって特にメリットが大きかったでしょう。

• 自社内クライアント向けの複雑でスケーラブルなアプリケーションをオンプレミスでセットアップするために膨大な可動パーツを利用していた顧客をいくつもお見かけしたことがあります。
  ここで鍵となるのが「複雑」と「スケーラブル」で、デフォルトのKubernetesクラスタを起動してアプリをそこで動かすことを私たちから顧客に打診するだけで済みます。Kubernetesが提供する環境は予測可能性が高く均一なので、アプリケーションをリリースするまでにマニフェストとHelmチャート¹を確実に完成させられます。

Kubernetesについてもうひとつ自慢できる点は、Kubernetesのスケーラビリティと拡張性が極めて高いことです。これを活用することで、（アーキテクチャ的に）比較的シンプルなアプリをホスティングすることも、あらゆるカスタム要件をすべて実装することも可能になります。

もちろん、コンテナの大規模なデプロイをオーケストレーションするコンテナオーケストレータなどのツールは他にもありますが、Kubernetesは本質的に、現代社会において100%ベンダーロックされることなく深いレベルまでコンテナをオーケストレーションするソリューションであり、現代のあらゆるクラウドでいつでもサービスとして利用可能です。

Kubernetesは基本的に、現代のクラウドプロバイダを本当の意味で使いやすく快適にするためにこれまで足りなかったものです。

もちろん、Kubernetesは独自ハードウェアでも実行できます。

Kubernetesをもっと楽に使うには

これまで私たちは長年にわたって多くのプロジェクトをサポートしてきましたが、さまざまな顧客のプロダクトを現実世界に公開する準備をしているうちに、実際はさまざまな顧客のKubernetesセットアップで同じような作業をたくさん行ってきたことに気づきました。

そこで、自然とこんなアイデアを思いつきます。
「自分たちがサポートする全顧客が、私たちが用意したKubernetesコンフィグのコアディストリビューションを参照する形にすればよいのでは？」

そこにインフラストラクチャの基本要素をもれなく詰め込んでおいて、クライアントのリポジトリにはそれをカスタマイズしたものを保存する形にしてはどうでしょう？

そして私たちはそれを実現しました！次に説明する設定パッケージは、Martian Kubernetes Kitという名前で呼ばれています。

Martian Kubernetes Kit

ポイントは次の通りです。
AWS EKSのようなマネージドソリューションであっても、最初に立ち上げたときのKubernetesクラスタはむき出しの空っぽな状態です。適切な監視も、実際のログ集約も、何もありません。しかし私たちが欲しかったのは、顧客が即座に完全なKubernetesエクスペリエンスを得るための方法でした。そこで登場するのがMartian Kubernetes Kitというわけです。
Martian Kubernetes Kitは、Kubernetesの利用開始をスムーズにするために設計されたターンキーソリューション²であり、現代のニーズに合わせて絶えず進化を繰り返します。

では、実証とテストを経た高信頼性ソリューションであるMartian Kubernetes Kitにはどんなものが入っているのでしょうか？

GitOps³は今や常識

Evil Martiansでは、プロジェクトが進化するに連れて「コードとしてのインフラストラクチャ」の重要性がますます高まると信じています。インフラストラクチャのコンポーネントと、それらに行った変更をトラッキングしていなければ、現在のインフラストラクチャがどうなっているのかを基本的に知りようがありません。

そこで私たちが選んだ方法は、クラウドプロバイダの設定にTerragruntとTerraformを利用し（現時点ではAWSとGCPに注力しています）、Kubernetesクラスタのコンテンツそのものの制御にはArgoCDを利用するというものです。

Terraformを選択することはわかりきっていました。Terraformはインフラストラクチャ管理ツールとして最も人気が高く、広く普及しています。しかも、外部のエンジニアがTerraformのコンフィグを理解して問題なく調整できるようになる可能性もずっと高まります。

そしてArgoCDは、最新のオープンソースCD（continuous delivery: 継続的デリバリー）ツールであり、適切なロールバックなどの必須機能や便利機能に加えて、より多くの開発者が簡単に利用できるUIも備えています。
また、必要に応じてコンフィグ全体を確実にアップグレード可能にするため、Kubernetesクラスタ上のセット全体をArgoCDで管理することにしました。

以上の作業すべてをできたてのKubernetesで行うとなると、何もかも手動で設定しなければならなくなるでしょう。Martian Kubernetes Kitを使えばそんなことにはなりません。

オープンソースの安価な監視を利用する

冒頭で、私たちの顧客の1つがカスタム変更を行ったときの費用を数万ドル節約できたかもしれないという話をしたのを覚えていますか？この顧客の場合、監視ソリューションを別のものに差し替えるだけでコストの大半を削減できた可能性があります。

もちろんビジネスモデルの予算が許すのであれば、DataDogのような有料監視サービスを利用するのはありですし、よいことです。しかしDataDogのコストが他のインフラコストよりも大幅にかさむかもしれないという以下のミームを見たことはありますか？

pic.twitter.com/eJtS5IynRb

— Jake (@JustJake) October 12, 2023

あるいは監視機能と使いやすさを考えてAWS CloudWatchを選ぶのもよいでしょう。しかしAWS CloudWatchはたしかに利用可能な形で存在していますが、コンフィグや使い勝手が非常に悪く、実際にAWS CloudWatchに依存していた顧客をこれまで一度も見かけていません。

しかしMartian Kubernetes Kitでは、Kubernetesを実行するためのPrometheusフォーマットのメトリクスが、「文字通り」すべてのコンポーネントで提供されています。そしてMartian Kubernetes Kitには、Kubernetesエコシステムから提供されたPrometheus + Grafanaという優秀な監視ソリューションがあります。

クラスタから収集できるデータ量は、デフォルトのPrometheusセットアップでも、AWS CloudWatchで通常表示される量と比べて既に際立っています。そして私たちはログ収集も改善しました。

安価なログ集約

上に加えてログ集約機能も必要です。Martian Kubernetes Kitにはログ集約と、使いやすいGrafana Lokiもデフォルトで含まれています。
ログ探索用インターフェイスは、監視ビューやメトリクスビューと同じGrafanaインスタンス内に表示されるので便利です。さらに、これは同等の製品はもちろん、オープンソースの同等のオプションと比べても安価な場合が多いことがわかってきました。

アプリを手軽にプレビューする

アプリをHeroku並みに手軽に起動してプレビューする方法が欲しくてたまらなかった方へ、私たちのセットアップはまさにそのために準備されています。レビュー対象となるプルリクにGitHub上でラベルを付けるだけで、アプリケーションのコピーが実行されてチームが作業できるようになります。プルリクを閉じるかラベルを削除すれば、アプリケーションのコピーは削除されます。これについては、Kubernetesクラスタのコンテンツを管理しているArgoCDが面倒を見てくれます。

記事冒頭で、最大30個のエンタープライズ規模のアプリをプレビュー用に同時実行している顧客の話をしましたが、このオプションが使えるようになれば、開発を迅速に進めるうえで実際に大きな要素となるので、私たちは、顧客がこの機能をできるだけ利用可能にするために多大な労力を注ぎ込みました。

クラスタアップグレードを予測可能にする

インフラストラクチャが古すぎて最新の状態を保つのが困難（もしくは不可能）な顧客がいくつもあった頃は、対応に追われて時間を溶かしまくっていました。しかしMartian Kubernetes Kitに移行したことで、この問題は起きなくなりました。Kubernetesとエコシステムは急速な進化を繰り返していますが、私たちは変化に追従する準備ができています。Martian Kubernetes Kitを最新の状態に保っていれば、それを利用しているすべての顧客に年2〜3回のクラスタアップグレードを提供できる自信があります。

Martian Kubernetes Kitを作った動機のひとつは、Kubernetesエコシステムにおける開発のテンポが超高速なことです。この速さについていくには準備が必要でしたが、Martian Kubernetes Kitというソリューションのおかげで準備を整えられました。

DNAを転移可能にする

もうひとつのポイント: Martian Kubernetes Kitは私たちの顧客専用ではありますが、私たちがMartian Kubernetes Kitに盛り込んだツールはすべてオープンソースで手に入るものばかりです。車輪を再発明する必要はありません。

私たちは、プロジェクトのバトンを他のメンバーに引き継ぐ必要が生じる日が来ることも念頭に置いていました。そのためには、他のエンジニアも効果的にインフラストラクチャを利用してサポートを継続可能な形でツールキットを作る必要がありました。

言い換えれば、私たちは社内にベンダーロックのような状態を絶対に作りたくなかったのです。

Martian Kubernetes Kitのその他の機能

Martian Kubernetes Kitの機能はこれだけではありません。
柔軟な秘密情報（secret）管理機能の統合、多数のシナリオに対応したCI/CDワークフロー、証明書管理に加えて、便利なスクリプトやHelmチャートテンプレートといった開発者の人生を楽にするグッズもひととおり揃えています。

Martian Kubernetes Kitの実際の動作

ある顧客における実際のケーススタディをもっと詳しく見てみましょう。
この企業は、AWS CloudFormationで管理されるAWS ECS上で自社のプロダクトをホスティングしていました。あるとき同社から、私たちのAnyCableを（メトリクス付きで）追加し、デプロイプロセスを手直しし（これはむき出しのCloudFormationでは恐ろしく困難で作業に手こずります）、さらにデータベースとデプロイプロセスに関するアラートを取得可能にしたいという要望を受けました。これらはすべて、いつでも利用可能な形でMartian Kubernetes Kitに収録されています。

別の顧客はスケーラブルなアプリを必要としていましたが、私たちがサポートするまではKubernetesのことをまったく知りませんでした。
そして現在の同社は、クラスタをまったく問題なく利用できています。それも、私たちが日単位でサポートすることなしにです！私たちが提供しているのは、定期的なアップデートと、たまに発生する修正だけです。

全般的に、私たちがこれまで手掛けてきた顧客のほとんどは、インフラストラクチャを自力で最新に保つことができませんでした。この問題は、何か問題が発生したときに最後の瞬間までつきまといます。
しかし私たちのソリューションによって複数のクラスタの管理がやりやすくなり、常に適切かつ予測可能な形でアップデートし続けられるようになります。

冒頭で予告した通り、次はクイックスタートガイドを紹介します。果たしてKubernetesは皆さんの要件に適しているでしょうか？

現状維持か、それともKubernetes導入か

私たちは、あらゆるプロジェクトがいつかKubernetesを導入する運命にあるとまでは思わないので、Kubernetesをひとつ覚えで導入するようなことはしません。しかしKubernetesが適しているのであれば、Kubernetes導入には大きなメリットがあります。なお、この選択には重み付けがされています。

率直に申し上げれば、Kubernetesへの移行が適していることを示す主な兆候は「今ある以上のものが必要になる」ことです。
たとえば「オートスケーリングの強化」「インフラストラクチャコストの削減」「制約の縮小」「マイクロサービスやサードパーティ製品を統合可能にする」などです。このサードパーティ製品は、たとえば私たちのAnyCableやimgproxyでも、カスタムデータベースでも何でも構いません。

もちろん、現在のセットアップでも同じようなカスタムの夢はおそらく実現可能でしょう。しかし、今後新たに発生した要件を特定プラットフォーム向けに合わせるときが来れば、コストは大きく跳ね上がるでしょう。今後そうした道に進んだ場合の長期的なコストとメリットは、真剣に検討しておく必要があります。その検討の場にはKubernetesがあるのです。

次のステップ

次回の記事では、私たちがMartian Kubernetes Kitを作ったときのさまざまな技術的決定について詳しく解説していますので、ぜひご覧ください！同記事では、基本的にKubernetesインフラストラクチャをどのような形で管理するかを決定するうえで役に立つ本格的な導入事例を紹介しています。

同記事全体は、以下のように進みます。

• クラウドインフラストラクチャを立ち上げて、コードを整理する
• GitOpsアプローチを適切な形でクラスタに適用する
• むき出しのKubernetesクラスタに加えるべき重要なコンポーネント群（およびそれらが必要な理由）
• アプリケーションのデプロイプロセスを、新しく作ったGitOpsフローに統合する
• 最後に、アプリの自動プレビューインスタンスをただちに利用可能な形に移行する方法

私たちは、「Kubernetesは量子ドライブサイエンスのような空想の産物ではない」ことがMartian Kubernetes Kitによって実証されたことを知っています。Kubernetesへの移行は、すぐ手に届くところにあるのです。

私たちのSREサービスについて興味がおありの方は、Evil Martiansの各種SREサービス事例を自由にご覧いただけますので、ぜひお気軽にお問い合わせください。
私たちは、Kubernetesが現在の姿になる前からKubernetesを使い続けており、そこで培った経験を活かして、お客様のプロジェクトにKubernetesを採用する適切なタイミングについて決定を下すお手伝いに参上いたします。私たちはいつでも出動できるようスタンバイしておりますので、元記事のフォームにてご連絡をお待ちしております。

関連記事

Kamal README: 37signalsの多機能コンテナデプロイツール（翻訳）

The post Kubernetesをスムーズに導入するEvil Martians特製Kubernetesツールキット（翻訳） first appeared on TechRacho.