システム運用の自動化を目指す「NoOps」。クラウドやサーバーレス、自動化ツールといった技術を活用してシステムに回復性を持たせ、障害からの自己修復を可能にする。回復性は、システム基盤であるプラットフォームと、その上で動作するアプリケーションの双方が持つ必要がある。

 ここでは、アプリケーションに回復性を持たせる設計のポイントを見ていこう。回復性設計の分かりやすいケースとして、ECサイトにおけるバッチ処理の例を紹介する。いつでもどこでも何度実行しても同じ結果が得られる「冪等性(べきとうせい)」をアプリケーションに実装することで、回復性を持たせることができる。

 あるECサイトで顧客からの注文データのステータスを毎日更新するバッチ処理があるとしよう。サービス開始当初はアクティブな注文は1000件程度で、処理をループで回しても長くて10分程度で完了していた。

 その後売上規模は順調に拡大し、数年後には毎日のアクティブな注文数は10万件を超え、バッチ処理に12時間以上かかるようになってしまった。処理負荷が高いためか、プログラムのフリーズやDB切断などで月に1〜2回、バッチ処理が途中で失敗してしまう。運用担当者が夜間張り付いて、再実行処理を行っている状況だった。

回復性設計導入前のバッチ処理の構成
[画像のクリックで拡大表示]

 このバッチ処理を、NoOpsの考え方に基づいて設計すると、どのようになるだろうか。

 バッチアプリケーションをNoOpsで実装するためのポイントは3つある。1つめは、処理を小さな単位(仮にJobとする)に分割して実行することだ。その上で、たとえ処理が失敗してもJobの再実行を可能にする。2つめは、Jobの実行を非同期化することだ。これにより、特定Jobの失敗に影響を受けずに他のJobを継続実行できるようにする。3つめは、リソースと帯域に配慮しながらJobの並列実行を設計することだ。

 NoOpsの実装には、まずバッチ起動時の処理に手を入れる。処理単位の粒度を小さくするため、10万件の注文ステータス更新処理のループを、10万個のJobに分割。非同期処理としてキューへ投入するループに変更する。

回復性を持たせたバッチ処理を設計する
[画像のクリックで拡大表示]

 処理単位のサイズは、回復処理の実行単位となる。できるだけシンプルに回復させるために、可能であればこれ以上分割できない処理を実行単位として設計したい。キューは基本的に1本で問題ないが、キューの回復性がNoOpsの実現可否に直結する。そのため、障害発生時やフェールオーバー時のメッセージの保全性や、再実行処理がAPIから呼び出せるか、といったキューの回復性に注意して設計する。必要に応じてプライオリティキュー(優先度付きキュー)なども併用可能だ。

 続いて、キューから受け取った個々のJobを実行する。通常は、順次Jobを実行するバッチサーバーを配置したくなる。ただしNoOpsの観点では、Job単位で新規インスタンスを生成、実行するサーバーレス関数を使いたい。サーバーレス関数には、Azure FunctionsやAWS Lambdaなどがある。

この先は日経クロステック Active会員の登録が必要です

日経クロステック Activeは、IT/製造/建設各分野にかかわる企業向け製品・サービスについて、選択や導入を支援する情報サイトです。製品・サービス情報、導入事例などのコンテンツを多数掲載しています。初めてご覧になる際には、会員登録(無料)をお願いいたします。