SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

【デブサミ2020関西】セッションレポート(AD)

クラウドネイティブで重要な4つの指標――AWSコンテナサービスで実現するアーキテクチャ【デブサミ2020関西】

【B-6】AWSコンテナサービスで実践するクラウドネイティブアーキテクチャ

  • X ポスト
  • このエントリーをはてなブックマークに追加

指標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の仕組みを構築できたという。

aws-fargate-fast-autoscalerによる自己修復的インフラストラクチャ
aws-fargate-fast-autoscalerによる自己修復的インフラストラクチャ

指標4. サービスの監視

 クラウドネイティブ以前のサーバ運用では、以下のようなメトリクスを監視することが当たり前だった。

  • サーバのディスク容量
  • CPU使用率
  • メモリ使用率
  • プロセスが実行されているか
  • ハードウェアの死活監視

 しかし、これらの監視設定をクラウドネイティブな環境へそのまま適用するのは得策ではない。なぜなら、アプリケーションをステートレスな構成にし、サーバのディスクサイズが自動的に増加する設定にしていれば、ディスク容量を意識する必要はほぼないからだ。また、CPUやメモリなどのリソースが枯渇する前に負荷分散できればサービスへの影響も抑えられる。つまりクラウドネイティブにおいては、クラウドの特性をふまえた監視設定を行うことが大切なのだ。

 クラウドネイティブにおけるサービス監視の観点として、谷氏は「システムが落ちていないか?」「エンドユーザーから見てサービスが正常か?」をチェックすることが重要であると語る。また、クラウドに適した監視をするために「モニタリング」「ロギング」「トレーシング」という3要素を取得することも推奨した。

 「クラウドネイティブを構成する4つの要素とそれぞれの考え方について、事例を交えてご紹介しました。けして一度にすべてを取り入れる必要はありません。まずは手を出しやすいものから、ご自身のプロジェクトにマッチした技術を取り入れてみましょう。このセッションがクラウドネイティブなアーキテクチャを模索するきっかけになれば幸いです」(谷氏)

関連リンク

この記事は参考になりましたか?

  • X ポスト
  • このエントリーをはてなブックマークに追加
【デブサミ2020関西】セッションレポート連載記事一覧

もっと読む

この記事の著者

CodeZine編集部(コードジンヘンシュウブ)

CodeZineは、株式会社翔泳社が運営するソフトウェア開発者向けのWebメディアです。「デベロッパーの成長と課題解決に貢献するメディア」をコンセプトに、現場で役立つ最新情報を日々お届けします。

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

【AD】本記事の内容は記事掲載開始時点のものです 企画・制作 株式会社翔泳社

この記事は参考になりましたか?

この記事をシェア

  • X ポスト
  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/12879 2020/10/13 12:00

おすすめ

アクセスランキング

アクセスランキング

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング