指標3. 自己修復的インフラストラクチャ
自己修復的インフラストラクチャとは、既知の一般的な障害に対して自動的にサービスを復旧させる機能を指す。この機能をアプリケーションレイヤー、仮想インフラレイヤー、ハードウェアレイヤーそれぞれに導入することで耐障害性の高いアーキテクチャを実現できる。
パブリッククラウドが提供するほとんどのサービスは、ハードウェアレイヤーの自己修復性が担保されている。また、サービスによってはアプリケーションレイヤーや仮想インフラレイヤーの自動修復の仕組みがサポートされているものもある。つまりクラウドサービスを利用することで、必然的に自己修復的インフラストラクチャを実現しやすい構造になるのだ。
AWSにおいて自己修復的インフラストラクチャを実現している機能としては、例えばAmazon ECSの必要タスク数を自動的に増減させるAuto Scalingが挙げられる。だが谷氏はある理由により、担当プロジェクトでこの機能を使用できない事態に直面したという。
「実は、先ほど述べたようなAWS CodeDeployによるBlue/Green Deploymentを採用している場合には、AWS ECSのAuto Scaling機能を使用できません。代替案として、Amazon ECSを含む10種類以上のAWSサービスに対して、マネージドなAuto Scalingを提供できるApplication Auto Scalingという機能が候補に挙げられました。
ですが、どちらの機能にも共通する課題があります。Amazon CloudWatchに集積したメトリクスの値をスケーリングのトリガーにするため、スケーリングが開始するまで数分ほどかかってしまうのです」（谷氏）
谷氏が担当したプロジェクトでは、サービスの特性上、瞬間的なアクセススパイクの発生が予想された。この負荷に耐えるには、スパイクを検知してから可能な限りスピーディーにスケールアウトして負荷分散させる仕組みが必要だった。
そこで谷氏の所属する開発チームが用いたのが、aws-fargate-fast-autoscalerというオープンソースソフトウェアだ。これは、AWS Step Functionsを起点にAWS Lambdaが起動してAmazon ECSのコンテナのメトリクスを取得し、その値をもとにコンテナの増減を制御する仕組みである。
aws-fargate-fast-autoscalerの強みは、ほぼリアルタイムに負荷状況を解析してスケーリングできること。これにより、開発チームはサービス要件にマッチするAuto Scalingの仕組みを構築できたという。
指標4. サービスの監視
クラウドネイティブ以前のサーバ運用では、以下のようなメトリクスを監視することが当たり前だった。
- サーバのディスク容量
- CPU使用率
- メモリ使用率
- プロセスが実行されているか
- ハードウェアの死活監視
しかし、これらの監視設定をクラウドネイティブな環境へそのまま適用するのは得策ではない。なぜなら、アプリケーションをステートレスな構成にし、サーバのディスクサイズが自動的に増加する設定にしていれば、ディスク容量を意識する必要はほぼないからだ。また、CPUやメモリなどのリソースが枯渇する前に負荷分散できればサービスへの影響も抑えられる。つまりクラウドネイティブにおいては、クラウドの特性をふまえた監視設定を行うことが大切なのだ。
クラウドネイティブにおけるサービス監視の観点として、谷氏は「システムが落ちていないか？」「エンドユーザーから見てサービスが正常か？」をチェックすることが重要であると語る。また、クラウドに適した監視をするために「モニタリング」「ロギング」「トレーシング」という3要素を取得することも推奨した。
「クラウドネイティブを構成する4つの要素とそれぞれの考え方について、事例を交えてご紹介しました。けして一度にすべてを取り入れる必要はありません。まずは手を出しやすいものから、ご自身のプロジェクトにマッチした技術を取り入れてみましょう。このセッションがクラウドネイティブなアーキテクチャを模索するきっかけになれば幸いです」（谷氏）
