指標1. Always On
谷氏がはじめに説明した指標は、Always Onだ。これは日本語で「常時稼働」を意味する概念である。Always Onを実現するうえで重要なのは、可用性と回復性を向上させることだ。クラウドプラットフォームの各種サービスは、これら両方の性質を兼ね備えているものが多い。そのため、なるべく少ない労力でAlways Onを実現するには、パブリッククラウドを適切に使いこなすことが肝要になる。
谷氏が担当したプロジェクトでは、運用工数を下げつつシステムの可用性・信頼性を向上させるため、マネージドなコンテナサービスであるAmazon ECS（on Fargate）を活用した。各種APIを独立したコンテナとしてAmazon ECSにデプロイし、Amazon CloudWatch Eventsを用いて特定時刻にAmazon ECS上でコンテナを起動させることでバッチ処理も実現した。
「コンテナは仮想マシンよりも起動が早いという特徴があります。そのため、Amazon ECSで実行されているアプリケーションの負荷が高くなったとしても、新しいコンテナをすぐに起動させて負荷の量をコントロールできる。さらに特定のコンテナが停止しても別のコンテナをすぐに立ち上げられるため、エンドユーザーへの障害影響を低減させられるのです」と、谷氏はコンテナ活用の意義について解説した。
指標2. Immutable Deployment
次の指標はImmutable Deploymentだ。これは、稼働中のサーバと別の環境に新しいアプリケーションをデプロイして動作検証し、問題がなければ新環境に切り替えて旧環境を削除するデプロイ手法を指す。Immutable Deploymentを実現する手段としては、Blue/Green DeploymentやCanaryが有名だ。
Blue/Green Deploymentは、アプリケーションの新・旧バージョンを並行稼働させて、無停止で新バージョンへとトラフィックを切り替えたり、何かの障害を検知したりした際には旧バージョンへとロールバックすることで、エンドユーザーへの影響を抑えるデプロイ手法だ。デプロイ管理に特化したサービスであるAWS CodeDeployにはBlue/Green Deploymentの機能がデフォルトで備わっている。
Canaryは、Blue/Green Deploymentによって並行稼働した新・旧バージョンのアプリケーションのうち、一部のエンドユーザーにのみ新バージョンを使用してもらい、安全性が確認できてから全ユーザーに機能を開放する手法だ。
AWS CodeDeployでBlue/Green DeploymentやCanaryなどを実施した場合にどのようなトラフィックの流れになるのか。そして自身の担当プロジェクトでImmutable Deploymentを実現するためにどのようなCI/CDパイプラインを構築したのかを、谷氏は説明していった。
指標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つの要素とそれぞれの考え方について、事例を交えてご紹介しました。けして一度にすべてを取り入れる必要はありません。まずは手を出しやすいものから、ご自身のプロジェクトにマッチした技術を取り入れてみましょう。このセッションがクラウドネイティブなアーキテクチャを模索するきっかけになれば幸いです」（谷氏）
