クラウドネイティブアプリケーションを設計するための15の基本原則

スケーラブルなクラウドネイティブ アプリケーションを設計するには慎重な検討が必要であり、アプリケーションを展開するためのクラウドが多数あるとしても、克服すべき課題はまだ数多くあります。分散コンピューティングは、非常に複雑であることで有名ですが、依然として現実です。同時に、ネットワークの不安定性により速度低下や予期しないエラーが発生する可能性もあります。クラウド ネイティブ アプリケーションは通常マイクロサービスであるため、これらの課題を克服するために特別に設計および展開する必要があります。

この記事では、クラウドネイティブ アプリケーションを設計し、Kubernetes にデプロイするための 15 の基本原則を紹介します。

原則1: 単一のポッドはほとんどの場合利用できない

Kubernetes は必要に応じて独自に Pod を終了することを決定できるため、Pod を作成するにはコントローラーが必要です。一度限りのデバッグを除き、単一の Pod をできるだけ使用しないようにしてください。

レプリカ セットを直接使用することはほとんど望ましくありません。

代わりに、Pod を作成する Deployment または StatefulSet が必要です。これは、複数のインスタンスを実行する予定があるかどうかに関係なく適用されます。これを自動化する理由は、Kubernetes では Pod の継続的なライフサイクルが保証されないため、Pod 内のコンテナに障害が発生した場合に備えて、複数のインスタンスを同時に実行する必要があるためです。

原則2: ステートフルコンポーネントとステートレスコンポーネントを明確に区別する

Kubernetes は、さまざまなリソースとそれらを管理するコントローラーを定義します。それぞれ独自の意味を持ちます。 Deployment、StatefulSet、DaemonSet とは何か、そしてそれらが何ができるのか、何ができないのかについて、多くの混乱が見られます。正しく行うということは、意図を明確に伝えることを意味し、Kubernetes は目標の達成に役立ちます。

Kubernetes を適切に使用すると、これを強制的に実行できますが、複雑なソリューションも多数存在します。簡単な経験則としては、StatefulSet ではすべてステートフルにし、Deployment ではすべてをステートレスにすることです。これが Kubernetes のやり方だからです。ご使用の際は公式ドキュメントをよくお読みください。

原則3: セキュリティ上の理由から、秘密の設定と非秘密の設定を分離して明確にする

ConfigMaps と Secrets の間には技術的な違いはほとんどありません。 Kubernetes 内でどのように表現されるか、またどのように使用されるか。たとえば、アプリケーション構成は ConfigMap に保存され、資格情報を含むデータベース接続文字列は Secret に属します。

原則4: 自動拡張オプションを有効にする

すべてのポッドが実際にはデプロイメントによって管理され、サービスによって前面に置かれているのと同様に、デプロイメントには水平ポッドオートスケーラー (HPA) の使用も常に検討する必要があります。

実稼働中のサービスの容量が不足することは誰も望んでいません。同様に、ポッドの容量割り当てが不十分なためにエンドユーザーが苦しむことを望む人は誰もいません。最初からこれに備えるということは、スケーリングは可能であり、実際に起こるという考え方を持たざるを得ないことを意味します。これは容量不足になるよりはるかに良いことです。

一般的なスケーラビリティ設計の原則に従って、各アプリケーション コンポーネントの複数のインスタンスを実行する準備をする必要があります。これは可用性とスケーラビリティにとって重要です。

HPA を使用して StatefulSet を自動的にスケーリングすることもできることに注意してください。ただし、ステートフル コンポーネントは通常、絶対に必要な場合にのみスケーリングする必要があります。

たとえば、データベースを拡張すると、大量のデータ複製と追加のトランザクション管理が発生する可能性があり、データベースの負荷がすでに高い場合は管理できない問題が発生する可能性があります。さらに、ステートフル コンポーネントを自動スケールする場合は、自動スケールを無効にすることを検討してください。特に、何らかの方法で他のインスタンスと同期する必要があるステートフル コンポーネントがある場合。代わりに、このようなアクションを手動でトリガーする方が安全です。

原則5: コンテナライフサイクル管理にフックすることで自動化を強化し、有効にする

コンテナーは PostStart フックと PreStop フックを定義できます。これらは両方とも、新しいインスタンスが開始されたことやそのインスタンスが間もなく終了することをアプリケーションの他のコンポーネントに通知する重要な作業を実行するために使用できます。 PreStop 関数は終了前に呼び出され、完了するまでの (設定可能な) 時間を持ちます。これを使用して、終了するインスタンスが作業を完了し、ファイルを永続ボリュームにコミットするなど、整然とした自動シャットダウンに必要なその他の作業を確実に実行します。

原則6: プローブを正しく使用して障害を検出し、自動的に回復する

分散システムは、単一プロセス システムと比較して、ますます直感に反した方法で障害が発生します。ネットワークは、障害の原因となる大きな新しい種類のものです。障害をより正確に検出できれば、障害から自動的に回復できる可能性が高くなります。

この目的のために、Kubernetes は検出機能を提供します。特に準備プローブは、失敗によってコンテナ (および Pod) がリクエストを受け入れる準備ができていないことが Kubernetes に通知されるため、非常に便利です。

明確なドキュメントがあるにもかかわらず、活性プローブは誤解されることがよくあります。失敗した活性プローブは、コンポーネントが永久に悪い状況に陥っており、解決するには強制的に再起動する必要があることを示します。

スタートアップ プローブは、他のプローブによるプローブをいつ開始するかを示すために Kubernetes に追加されます。したがって、これは、実行することが意味を持ち始めるまで、それらを延期する方法です。

原則7: 欠陥のあるコンポーネントを迅速に発見する

アプリケーション コンポーネントは、ハード フェイル (クラッシュ)、ファスト フェイル (何か問題が発生するとすぐに)、およびラージ フェイル (ログに情報エラー メッセージが記録される) します。そうすることで、アプリケーション内でデータが異常な状態で停止することがなくなり、トラフィックが正常なインスタンスにのみルーティングされ、根本原因の分析に必要なすべての情報が提供されます。この記事で紹介したすべての自動化とその他の原則は、根本原因を見つけながらアプリケーションを良好な状態に保つのに役立ちます。

コンポーネントとクラスター自体の両方で。障害は避けられないため、アプリケーション内のコンポーネントは障害や再起動を自動的に処理できる必要があります。

原則8: 可観測性を確保する

監視、ログ記録、トレースは、可観測性の 3 つの柱です。監視システムにカスタム メトリックをフィードし、構造化されたログ (JSON 形式など) を書き込み、HTTP ヘッダー (相関 ID を含むヘッダーなど) を意図的に削除せずに記録されたコンテンツの一部として含めるだけで、アプリケーションで監視可能なすべての情報が提供されます。

より詳細な追跡情報が必要な場合は、アプリケーションを Open Telemetry API と統合します。ただし、前の手順により、人間のオペレーターでも自動化でも、アプリケーションを簡単に監視できるようになります。ほとんどの場合、CPU 使用率などの生のメトリックではなく、アプリケーションにとって意味のあるメトリックに基づいて自動スケーリングを行う方が適切です。

SRE の「4 つのゴールデン シグナル」は、レイテンシ、スループット、エラー、飽和度です。経験上、アプリケーション固有のメトリックを使用してこれらの監視信号を追跡する方が、共通のベース ソースから取得した生のメトリックを使用するよりもはるかに有用です。

原則9: Podリソース要求を適切に制限する

Horizo​​ntal Pod Autoscaler と Cluster Autoscaler はどちらも、Pod リソース要求と制限を適切に設定することで、より優れたパフォーマンスを発揮します。必要な容量と利用可能な容量がわかっていれば、ポッドとクラスター全体に必要な容量を判断するのがはるかに簡単になります。

リクエストや制限を低く設定しすぎないでください。これにより、クラスターでより多くのポッドを実行できるようになるため、最初は魅力的に思えるかもしれません。ただし、リクエストと制限が同じに設定されていない限り (Pod に「保証された」QoS クラスが付与される)、通常の (通常のトラフィックの) 操作中に Pod がより多くのリソースを取得する可能性があります。すべて正常に動作しているようです。ただし、ピーク時には、QPS は指定した数に制限されます。スケールアップは、実際には、デプロイされた各ポッドがより多くのリソースを使用することを意味しますが、全体的なパフォーマンスは低下する可能性があります。

原則10: 容量を確保し、ポッドを優先する

容量管理の点では、名前空間のリソース割り当て、ノード上の予約済みコンピューティング リソース、適切な Pod 優先度設定により、クラスターの容量と安定性が影響を受けないようにすることができます。

クラスターの負荷が高くなりすぎて、ネットワーク プラグイン Pod が削除されないように注意してください。

原則 11: 必要に応じてポッドを強制的に結合または分割する

ポッドの分散制約とアフィニティおよび反アフィニティ ルールは、ポッドを同じ場所に配置したり (ネットワーク トラフィックの効率化のため)、分散したり (冗長性のため) して、複数のクラウド リージョンにわたる可用性を確保するための優れた方法です。

原則12: ダウンタイムが発生する可能性のある計画された操作中にポッドの可用性を確保する

Pod 中断予算は、一度にいくつの Pod (たとえば、デプロイメント内) を自発的に中断できるか (つまり、障害ではなくコマンドによって) を指定します。これにより、管理者が一部のクラスター ノードを使用不可としてマークした場合でも、高可用性を確保できます。これは、たとえばクラスターのアップグレード中に発生し、Kubernetes の更新が非常に速いため、通常は月に 1 回程度発生します。

Pod 中断予算を誤って設定すると、管理者がクラスターのアップグレードを実行する機能が制限される可能性があることに注意してください。これにより、オペレーティング システムの自動パッチ適用が妨げられ、環境のセキュリティ体制が危険にさらされる可能性があります。

PDB は、自発的な停止により同時にダウンする可能性がある複製されたアプリケーションの Pod の数を制限します。

原則 13: ダウンタイム デプロイメントよりもブルー/グリーン デプロイメントまたはカナリア デプロイメントを選択する

現代において、メンテナンスのためにアプリケーション全体をシャットダウンすることは許されません。これは現在、アプリケーションが一時的にアクセス不能になる「stop-the-world デプロイメント」として知られています。より洗練された展開戦略により、よりスムーズで段階的な変更を実現できます。エンドユーザーは、アプリケーションが変更されたことをまったく知る必要はありません。

ブルー/グリーンおよびカナリアデプロイメントはかつては難解な技術でしたが、Kubernetes によって手頃な価格で誰でも利用できるようになりました。コンポーネントの新しいバージョンをより速く展開します。独自のスクリプトで多かれ少なかれ手動で実装する必要があるかもしれませんが、より良い方法は、ArgoCD (blue/green または canary) などの高度なデプロイメント戦略を実行するための CD リリース ツールを選択することです。

技術的なレベルでは、ほとんどのデプロイメント戦略は、同じコンポーネントの 2 つのバージョンを同時にデプロイし、それらへのリクエストを別々に分割することに要約されます。これは、たとえば、新しいバージョンの Pod の 5% に適切なラベルをタグ付けして、サービスがトラフィックをそれらの Pod にルーティングするようにすることで、サービス自体を通じて行うことができます。あるいは、今後リリースされる Kubernetes Gateway がそのまま使用できる状態になります。

原則14: ポッドに不要な権限を与えないようにする

Kubernetes は本質的に安全ではなく、デフォルトでも安全ではありません。ただし、コンテナがノード上で実行できるアクションを制限するなど、セキュリティのベスト プラクティスを適用するように構成できます。

コンテナを非ルートユーザーとして実行します。コンテナ イメージが Docker で構築され、コンテナがデフォルトでルートとして実行されるという事実は、おそらく 10 年近くハッカーの天国となってきました。コンテナのビルド プロセス中は root のみを使用して依存関係をインストールし、その後非 root ユーザーを作成してアプリケーションを実行します。

アプリケーションに昇格された権限が必要な場合は、非ルート ユーザーを使用し、すべての Linux 機能を削除して、最小限の機能セットのみを追加します。

原則15: クラスター内でポッドが実行できることを制限する

デフォルトのサービス アカウントをアプリケーションに公開しないでください。 Kubernetes API と対話する特別な必要がある場合を除き、デフォルトのサービス アカウント トークンをインストールしないでください。ただし、Kubernetes ではデフォルトでこれが許可されます。

安全でない動作モードがデフォルトで不必要に有効にならないように、可能な限り厳格な Pod セキュリティ ポリシーを設定して適用します。

ネットワーク ポリシーを使用して、Pod が接続できる他の Pod を制限します。 Kubernetes の障害のないデフォルト ネットワークは、攻撃者が 1 つの Pod に侵入するだけで他のすべての Pod に直接アクセスできるため、セキュリティ上の悪夢となります。

Log4Shell は、ホワイトリストに登録されたトラフィックを除くすべての出力トラフィックを禁止するロックダウンされたネットワーク ポリシーを持つコンテナーに対してはまったく効果がありません (エクスプロイトからの LDAP サービスは機能しません)。

まとめ

この記事では、クラウドネイティブ アプリケーションを設計し、Kubernetes にデプロイするための 15 の原則を紹介します。これらの原則に従うことで、クラウドネイティブ アプリケーションは Kubernetes ワークロード オーケストレーターと連携できるようになります。そうすることで、Kubernetes プラットフォームとクラウドネイティブなソフトウェアの設計および運用方法によってもたらされるすべてのメリットを享受できるようになります。

Kubernetes リソースを正しく使用する方法、自動化を準備する方法、障害を処理する方法、Kubernetes プローブを使用して安定性を向上させる方法、アプリケーションを監視可能に準備する方法、Kubernetes スケジューラを機能させる方法、高度なポリシーを使用してデプロイメントを実行する方法、およびデプロイされたアプリケーションの攻撃対象領域を制限する方法について学習しました。

これらの側面をソフトウェア アーキテクチャ作業に組み込むことで、日常の DevOps プロセスをよりスムーズかつ信頼性の高いものにすることができます。