AWS初心者でもサーバレスでここまでできる――クラウド運用の定型業務を9カ月で自動化した新入社員の挑戦：特集：「惰性をやめる、慣習を疑う」こんどこそ楽になる運用管理（2）

運用管理者に光を当てるオンラインイベント「Cloud Operator Days Tokyo 2021」。NTT東日本のセッション「新入社員が9ヶ月でクラウド運用の自動化システムを作ってみた」から、AWS初心者が運用監視の定型業務を自動化する際の流れ、苦労するポイントを学ぶ。

[谷崎朋子，＠IT]

東日本電信電話の坂齊史奈子氏

　日々、何げなくこなしている業務の多くは定型業務だ。自動化することで一気に効率を引き上げることができる――そんなミッションに取り組んだのは、Amazon Web Services（AWS）に触ったのが入社してから初めてという東日本電信電話（NTT東日本）の新入社員、坂齊史奈子氏。

　「Cloud Operator Days Tokyo 2021」のセッション「新入社員が9ヶ月でクラウド運用の自動化システムを作ってみた」で、クラウド運用監視の定型業務を自動化した際の流れ、苦労するポイントを講演した。

クラウドサービス活用が進んだ結果、監視業務が逼迫

　2020年にNTT東日本に入社した坂齊氏は、機械工学科出身。クラウドやプログラミングの経験が全くない中で配属された先は、クラウドの運用業務やDX（デジタルトランスフォーメーション）推進案件を実施する部門。そんな同氏が課せられたのは、繰り返し発生する定型業務の自動化だった。

　コストメリットやデプロイの速さ、運用保守の簡素化といったメリットがあるクラウドサービスは、多くの企業で積極的に採用されている。NTT東日本も例に漏れず、「クラウドサービスの利用状況は増加傾向にある」と坂齊氏は言う。

　しかし、それと併せてある問題が浮上した。それは、クラウドサービスの運用監視業務の逼迫（ひっぱく）だ。

　同社では、クラウドサービスやサービス内のインスタンスのリソースでエラーが発生または回復した際に、アラート通知を出すように設定している。通知は運用組織が受け取り、アラートの内容を確認。「どのサービスで発生したのか」「アラートの種類は何か」を確認したら、フローに沿って運用組織などの該当先に通知すべきかどうかを判断する。通知が必要な場合は、通知先と文面を用意し、ミス防止でダブルチェックを行ってからメール送信。送信後は記録ソフトウェアを使って情報を記録していた。通知が不要な場合は、情報を記録して終了だ。

　しかし、クラウドサービスの数が増え、年間2500件超のアラートが発生するようになった結果、運用業務の稼働が奪われていった。今後もクラウドサービスを利用するのは目に見えており、このままでは運用組織の疲弊は避けられない。

　問題を解消すべく、坂齊氏たちはアラート発生〜記録という一連の業務フローの棚卸しを実施。かなりの部分で単純な定型業務が繰り返し発生していることが分かった。これを自動化すれば、業務逼迫の現状を解消できるかもしれない――坂齊氏たちは、早速自動化に取り掛かることにした。

運用監視業務で繰り返し発生する単純業務が、利用するクラウドサービス数の増加で業務逼迫の原因に（坂齊氏の講演資料から引用）

連結フローを視覚的に把握できるAWS Step Functionsを採用

　自動化システムは、もちろん最小限の運用負担で回せるようにしたい。そこで、AWSのサーバレスアーキテクチャで構築することに決定。アラートの確認と種類特定、フローの確認、通知の有無の判断は、「AWS Lambda」と「Amazon DynamoDB」を使って通知判断機能として実装。通知先や文面の確認、メール送信の流れはLambdaと「Amazon Simple Email Service」（SES）を基本に、「Amazon Simple Storage Service」（S3）やDynamoDBを組み合わせたメール送信機能として実装。記録機能は、LambdaとDynamoDBを組み合わせることにした。

　「Lambdaは、サーバのプロビジョニングや管理が不要でコードを実行できるコンピューティングサービス。今回のような通知判断機能やメール送信機能といった、ちょっとした処理が得意」。そう説明する坂齊氏は、本件ではコードの複雑化とランタイムエラーの防止を目的に、Lambdaを機能ごとに実装し、複数のLambdaを連結させることにしたという。

　アプリケーションの連結方法には、「Amazon Simple Queue Service」（SQS）、「Amazon EventBridge」「AWS Step Functions」の3つを暫定的に選定。Lambdaから別のLambdaを呼び出す簡易構成をそれぞれの手法で構築し、比較検討することにした。

　動かして比較したことで、それぞれの特徴や扱いやすさなどが実感できた。

　「SQSは、キューを作成して別のLambdaを呼び出す仕組み。構成が複雑になったときにキューのコードも増え、管理が大変そうに見えた。EventBridgeは、イベントを作成して別のLambdaを呼び出し、呼び出した先でイベントを削除する必要があった。これも複雑な構成になったときに扱いづらくなると感じた」

　一方のStep Functionsは、サービスの連結フローをコードで記述するサービスだ。特に同氏は書いたコード内の連結フローが視覚的に描画され、一目でコードの中身が分かることや、実行結果（成功、失敗）が色分けで表示されて問題箇所がすぐに把握できること、「AWS CloudWatch」を見に行かなくてもStep Functions内でエラーログを確認できることなどを高く評価。「今後構成が複雑になったとしても、何とか乗り切れるかもしれない」と思えたことも、最終的な決め手になった。

Lambdaの連結方法として、SQS、EventBridge、Step Functionsを検討（坂齊氏の講演資料から引用）

自動化システムの開発で多くの学びを得る

　最終的に出来上がった自動化システムは、下図の通り。全体の流れとしては、監視システムからのアラートをいったんEventBridgeで受けてから、Step Functionsのワークフローを呼び出す仕組みにした。

自動化システムの全体像（坂齊氏の講演資料から引用）

　ワークフロー内には、Lambdaを3つ配置した。

　1つ目のLambdaは、通知判断機能を実装した。DynamoDBであらかじめ収集、記録したアラート情報を参照し、アラート情報テーブルから関連部署への通知の有無を判断。さらに、Step Functionsの「Choice」機能で分岐を設定。アラートを通知する場合は2つ目のLambdaを呼び出し、アラートの通知が不要の場合は終了するようにコーディングした。

　「分岐の設定で、Lambdaの条件分岐（if文）を使うか、Step FunctionsのChoice機能を使うかは悩みどころだ。注意したいのは、Step Functionsの料金はステート数に応じて課金されること。そのため、Choice機能を乱用するとステート数が増え、料金も上がる。Choice機能が増えると、Step Functionsのフローが少し読みにくくなる。どちらを選択するかは、将来的な拡張性を考慮した上で、適度に処理を分けることをお勧めする」

　2つ目のLambdaは、メール送信機能を実装した。アラートの通知先や通知内容をDynamoDBやS3にアクセスして取得。SESや「Amazon Simple Notification Service」（SNS）を使ってアラートメールを送信する。

　3つ目のLambdaは、記録機能を実装。これはDynamoDBで対応した。

　自動化システムの構築で苦労した点について、坂齊氏は次のように語る。

　「苦労したのは、実業務をLambdaに反映する際のPythonなどのコーディング。自動化システム構築に向けて、2カ月かけてクラウドの基礎知識などを勉強したが、コーディング経験がないために苦戦した。リリースに当たって実施組織に何が変わるのかを説明することになったが、AWSやシステムに詳しくない人たちが聞き手ということで、いかに分かりやすい言葉や表現で伝えるかで苦労した」

　勉強を始めて2カ月目に入ってから、坂齊氏は現場業務の棚卸しや要件定義を開始した。そして3カ月目には全体の設計やLambdaおよびStep Functionsの構築を実施。テスト、リリース準備、そしてシステムの最終リリースができたのは9カ月後のことだった。

自動化システム構築までの流れ（坂齊氏の講演資料から引用）

　「Step FunctionsのコードはJSONで書くが、初めてだったために最初はためらったものの、AWSの公式ドキュメントや先人たちの技術ブログにテンプレートがたくさん掲載されていた」。そう述べる坂齊氏は、そのおかげでコーディングのハードルが下がって取り組みやすくなったことを明かす。

　「繰り返し作業や定期的に実行する処理フローなどの大半は自動化が可能。日々の業務で自動化できるものが見つかったら、ぜひ挑戦してみてほしい」

特集：「惰性をやめる、慣習を疑う」こんどこそ楽になる運用管理

ITがビジネスを加速させる昨今、多くの新規サービスが開発、リリースされ、運用管理者には安定したサービスの供給や、利用動向のログの解析などが求められている。だが、これに伴い解析すべきログや拾うべきアラートも増す一方となり、多大な負担が運用管理者の身に振り掛かっている。また、新規サービス開発でのクラウド活用、基幹システムのクラウド移行が進み、可用性や柔軟性といったクラウドならではの特性を生かす、いわゆるクラウドネイティブなアプリケーションの運用が増え、コンテナやマイクロサービスといった複雑な運用管理も求められている。しかも、オンプレミスに残さざるを得ないサーバとのハイブリッドな運用も並行しなければならない。このような中、従来の手法や技術では、とうてい運用管理業務が回らず、ビジネスに貢献することができないのが実情だ。現状を打破するためには、従来の慣習を疑い、新しい技術や自動化、AI（人工知能）などを取り入れ、現状に合った新たな運用管理の手法を実践することが大前提となる――本特集では、運用管理の最新技術や使いこなし方を徹底的に深掘りする。

特集：「惰性をやめる、慣習を疑う」こんどこそ楽になる運用管理