クラウドネイティブ環境向けに設計する

必要な動作を定める

クラウドネイティブの実践は、パブリック、プライベート、ハイブリッドの各環境で、繰り返し可能な開発と運用を支えます。CNCFは、変化しても管理、観察、障害への耐性を保つシステムを重視しています。コンテナーやオーケストレーションは、この方法を支援できます。それだけで、すべての性質が得られるわけではありません。

架空のレポートサービスから始めます。AIツールが、エンドポイント、ワーカー、コンテナーイメージを作ります。デモでは正しいPDFが生成されます。本番の前に、別の問いに答える必要があります。ジョブの途中で、プラットフォームがワーカーを置き換えるとどうなりますか？

これはインフラだけでなく、アプリ設計の問いでもあります。再起動でプロセスが戻っても、未完了の作業は失われるかもしれません。

プロセスと永続的な状態を分ける

試作品は、待機中のジョブと完成したレポートをコンテナーのディスクに置いています。コンテナーを置き換えると、両方が失われる可能性があります。ワーカーを増やすと、どのワーカーがリクエストを受けたかで、結果が変わる場合もあります。

改良した設計では、永続的なジョブ保管先と、承認済みのオブジェクトストレージを使います。リクエストはジョブの識別子を記録します。ワーカーはジョブを取得し、結果を作成して、その場所を記録します。利用者がレポートをダウンロードするときも、アクセス確認は必要です。

シークレットをイメージに含めないでください。承認済みのシークレット管理システムから供給します。どの設定変更に、新しいリリースやプロセスの再起動が必要かを記録します。

ワーカーを増やす前に再試行を設計する

ワーカーがPDFを保存し、ジョブ完了を通知する前に停止したとします。キューはそのジョブを再配信します。二回目の試行で、顧客への二重請求や矛盾する完了メッセージが発生してはいけません。

適切な箇所では、冪等な操作を使います。同じ論理リクエストを繰り返しても、意図した効果を保つようにします。安定したリクエスト識別子を定め、結果を永続的に記録し、各障害地点での動作を確認します。AWSは安全な再試行のガイドで、この方法を説明しています。

再試行にも上限が必要です。タイムアウト、再試行回数の上限、同時の再送を避ける遅延を設定します。永遠に繰り返すのではなく、失敗した作業を調査用に保存します。

望ましい状態をレビュー可能にする

宣言的な設定は、意図するデプロイ状態を示します。コントローラーは、その状態を維持しようと動作します。例えば、Kubernetes Deploymentはアプリのレプリカと管理された更新を扱います。それでも、アプリは置き換えを正しく処理する必要があります。

インフラとアプリの設定をバージョン管理します。通常の提供プロセスで変更をレビューします。ジョブの実際の完了、キュー内の待ち時間、失敗、依存先の上限を観察してください。プロセスが動いていても、レポートを生成できない場合があります。

チームが運用できるプラットフォームを選ぶ

クラウドネイティブにするために、すべてのアプリをマイクロサービス化する必要はありません。マネージドランタイム上のモジュール化されたアプリでも、要件を満たせます。サービスを増やすと、インターフェース、デプロイの判断、運用作業も増えます。

開発エージェントに、実際のプラットフォームの仕様と制約を渡します。サポートするランタイム、ID管理の方法、データサービス、デプロイのルール、必要な証拠を含めます。成功するリクエストだけでなく、中断や置き換えの動作もテストします。次に可用性と障害の範囲を学んでください。