最初からKubernetes上でアプリケーションを構築すべき理由

新しいアプリ、サービス、Web サイトなど、新しいプロジェクトをゼロから開発している場合、主な懸念事項は通常、可用性の高いネットワークを使用して大規模に実行することではありません。代わりに、ターゲット顧客に適した製品の構築や、製品と市場の適合性の追求に重点を置くことができます。スタートアップ向けの MVP を作成する場合、スケールアップする前にこの最小限の実行可能な製品を完成させる必要があります。そうしないと、誰のためにスケールアップするのでしょうか?企業の開発者であれば、現在行っているビジネスが期待とニーズを満たしているかどうかを確認したいはずです。運用のスケーリングは、せいぜい明日のことです。

[[419835]]

したがって、適切なテクノロジーのセットを選択する場合、Kubernetes (通常は大規模な分散システムに関連付けられます) は現時点では考慮されていない可能性があります。結局のところ、クラスターのセットアップと運用、アプリケーションのコンテナ化、サービス、デプロイメント、ロードバランサーの定義など、かなりの作業が伴います。これは初期段階ではやり過ぎのように思われるかもしれませんし、実際のアプリケーションの最初の数回の反復の作成など、他のタスクに時間を費やした方がよいと判断するかもしれません。

2008 年に Stack Overflow の構築を開始したとき、私たちには選択の余地がありませんでした。 Docker (2013) も Kubernetes (2014) もありませんでした。クラウド コンピューティングはまだ初期段階でした。Azure はリリースされたばかり (2008 年)、Amazon Web Services は開始されてから 2 年ほどでした。私たちが構築するものは特定のハードウェア向けに設計されており、それについて多くの仮定に基づいています。現在、コードベースを最新化し、クラウドに移行しているため、Kubernetes とコンテナを適切に動作させるために多くの作業を行う必要があります。

このプロセスを経ると、まったく新しい視点が得られます。現在、新しいアプリケーションを構築している場合は、最初からクラウドネイティブにして Kubernetes を使用することを詳しく検討する価値があるかもしれません。 Kubernetes のセットアップには、思っているよりも少ない作業しか必要ありません。また、後でコンテナ化をサポートするためにアプリケーションをリファクタリングするよりも作業が少なくて済みます。

ここでは、最初から Kubernetes 上でアプリケーションを構築することが必ずしも悪い考えではない 3 つの理由を説明します。

マネージドKubernetesが重労働を担う

数年前、Stack Overflow で最初の社内 Kubernetes クラスターをセットアップしたとき、VM のプロビジョニング、インストール、構成、構成、構成と、すべてを稼働させるのにほぼ 1 週間かかりました。クラスターが起動されると、継続的なメンテナンス タスクになります。このプロセスを通じて私たちが得た最大の収穫は、Kubernetes は私たちにとって素晴らしいものだが、他の人にも使ってもらいたいということだ。

現在、Amazon の Elastic Kubernetes Service (EKS)、Microsoft の Azure Kubernetes Service (AKS)、Google の Google Kubernetes Engine (GKE) などのマネージド Kubernetes サービスを使用すると、数分で独自のクラスターをセットアップできます。たとえば、AKS では、ポータル内のいくつかのボタンをクリックして、いくつかのフォームに入力するだけです。

これは便利ですが、ワークフローの最後にクラスターを作成するという近道はおそらく望ましくないでしょう。まずウィザードを完了してください。ただし、最後に青い「作成」ボタンをクリックしないでください。代わりに、作成した構成を ARM テンプレートとしてダウンロードし、ソース管理システムに取り込みます。これで、使いやすさと Infrastructure as Code (IaC) の両方の長所を享受できるようになりました。

ここで設定を済ませれば、クラウド プロバイダーに多額の小切手を送ること以外、アプリケーションを拡張するためにやるべきことはほとんどなくなります。追加のリソースの割り当ても簡単です。規模に伴う問題（フォールト トレランス、負荷分散、トラフィック シェーピング）に対処しました。成功に圧倒されることはありません。余分な作業をかけずに、アプリケーションを将来にわたって使用できるようにすることができます。

クラウドに依存しない

プロジェクトが成功すれば、初期段階で下された技術的な決定が、数か月または数年後にも影響を与え続ける可能性が高くなります。たとえば、Stack Overflow はもともと C# で書かれていました。 13 年経った今でも、まだ C# で書かれていますが、それは昔の話です。時々、Node.js で書き直すことを提案する人もいました。しかし、それは今まで起こっていません。

クラウド サービスへの依存についても同様です。 Amazon の EC2 などの Infrastructure as a Service (IaaS) サービス上に新しいアプリケーションを構築できます。あるいは、Microsoft の Azure SQL などのサービスとしてのプラットフォーム (PaaS) サービスに依存し始めることもできます。しかし、現段階で、その背後にあるクラウド プロバイダーに対して長期的なコミットメントを行う意思はありますか?旅の行き先がまだわからない場合は、しばらくはクラウドに依存しない方が良いかもしれません。

インフラストラクチャ・アズ・コードに戻りましょう。Terraform などのツールを組み合わせることで、ある程度クラウドに依存しない状態を維持できるようになります。さまざまなクラウドやインフラストラクチャ プロバイダーにまたがるリソースを管理するための統合ツールキットと構成言語 (HCL) を提供します。アプリケーションが本当にクラウドに依存しないということはまずありませんが、その場合は、自宅でインターネットや電力会社を切り替えるのと同じくらい簡単にクラウド プロバイダーを切り替えることができます。

HashiCorp フォーラムには、このトピックに関する優れた議論があります: Terraform は本当にクラウドに依存しないのでしょうか?コメント投稿者の一人は次のように指摘した。

「Kubernetes クラスターは、コンピューティング リソースの抽象化の優れた例です。さまざまなプラットフォーム上にホスト型および自己管理型の実装が多数存在し、それらはすべて共通の API と共通の機能セットを提供します。」

それはかなりうまくまとめていますね！まだ完璧な抽象化ではありません。たとえば、各クラウド プロバイダーは、Kubernetes のパブリック ロード バランサーや永続ボリュームなどを実装するための独自のカスタム方法を持っている場合があります。公平に言えば、Kubernetes 上でアプリケーションを構築する場合、ある程度はクラウドに依存しない状態が維持されます。

いつでも簡単に新しい環境を立ち上げることができます。

Kubernetes は、多くの場合、運用インフラストラクチャを管理する方法として認識されています。しかし、Stack Overflow では、テスト環境を動的に管理するためにこれを常に使用しています。私たちは、Kubernetes を使用して PR 環境と呼ばれるものをホストしています。ボタンをクリックするだけで、各プル リクエストを分離されたテスト環境で実行できます。

「分離された環境」とは、アプリケーション自体 (PR ブランチでコードが変更されたもの) と、SQL Server、Redis、Elasticsearch、および追加サービスの独自のインスタンスなど、すべてを意味します。これらはすべて、ほんの数分でゼロから開始され、あなたとあなたの PR に関心のある他のユーザー専用の専用の名前空間内の少数のコンテナーで実行されます。

私たちがこれを発明したわけではありません。他の組織ではこの概念を長い間使用してきました。すべてのコード変更はプル リクエストを介して Git などのバージョン管理システムに取り込まれるという考え方です。他の開発者がコードをレビューしますが、コードがすべてではありません。コードが実際に動作するのを確認したい。通常は、すべてのコードをローカルにダウンロードし、コンパイルして実行する必要があります。これは単純なことかもしれませんが、複数のリポジトリからコードを取得する必要がある大規模なアプリケーションやマイクロサービス アーキテクチャを実行している場合は、何時間もデバッグが必要になる可能性があります。

もっと理想的に考えて、新しい機能のすべてのコミットを 1 つにまとめ、単一の PR として送信したと仮定しましょう。この PR 環境をリンクとして営業またはマーケティングに送信し、実際の機能をプレビューできるようにします。営業チームが特定の機能やカスタムビルドを備えたアプリケーションのデモを希望する場合は、PR 環境へのリンクを直接送信します。スキルの低い同僚にビルド プロセスを指導するのに時間を費やす必要はありません。

ここまで到達するには、多くの準備が必要です。まず、Windows コンテナーで従来の .NET Framework を実行することは、私たちが追求したい道ではありません。理論的にはこれは可能です (Kubernetes はバージョン 1.19 以降 Windows をサポートしています) が、Docker/Kubernetes エコシステムは実際には Linux 中心です。幸いなことに、.NET Core への移行はすでに進行中だったので、Linux コンテナーに賭けることにしました。

もちろん、これによって独自の課題も生じます。 10 年以上前のコードベースを扱う場合、ハードコードされたファイル パス (お気に入りのフォワード スラッシュとバックスラッシュを含む)、サービス URL、構成など、コードベースが実行されるインフラストラクチャに関する想定が見つかる可能性があります。しかし、最終的にはそれが実現し、今では自動スケーリングされた Kubernetes クラスター上で、Stack Overflow、Stack Exchange ネットワーク、Teams 製品のテスト インスタンスをいくつでも起動できるようになりました。

Stack Overflow の初期の頃に、このようなツールがあったら話は違っていたでしょう。製品構築の初期段階では、通常、できるだけ早く構築、測定、学習を行うことが望まれます。コンテナと Kubernetes を使用すると、このようなツールを構築して、拡張が必要になったときに将来に備えることができます。

では、最初から Kubernetes を使用すべきでしょうか?おそらく！もちろん、これは特定のプロジェクト、ニーズ、優先順位によって異なります。

しかし、「製品と市場の適合性がまだ確立されていないため、Kubernetes は必要ありません」と言っていませんか?考えてみると、「まだ製品と市場の適合性が得られていないため、Kubernetes が必要です」と言うかもしれません。