改めまして、基盤デザイン事業部の小林です。
さて、皆さんは基盤（インフラ）担当というとどういったお仕事を想像されますか？
もちろんこの答えは会社ごと、さらには部署ごとにそれぞれ異なると思いますので、私たち基盤デザイン事業部の視点でお話しさせていただきます。
（なお、これは現在の形であり、時代によってチーム分けなどの形に変遷はありますので、あくまで現時点の話とご理解ください。）
案件によって多少の違いはあるのですが、私たちの仕事には基本的に下記のような作業が発生します。
- サーバ上で動作するアプリケーション（アプリ）の開発
- アプリが動作するためのAWSサービスやサーバといった環境（インフラ）の設定・構築
- 実運用開始後のアプリの不具合対応や脆弱性対応、機能追加といった改修
- 実運用開始後の各種設定変更
- 実運用開始後のシステム障害発生時の対応
私たちはこれらの作業をアプリ担当チームとインフラ担当チームで手分けして担当しています。 上に挙げたものでは、1、3をアプリ担当チーム、2、4、5をインフラ担当チームで行っていることが比較的多いです。
つまりインフラ担当者は「インフラの構築」だけでなく、「実運用開始後のシステムの面倒を見る」ことも業務のひとつとなっています。
具体的な技術で言うと、ネットワークやサーバといった構築に関わる知識だけでなく、運用やトラブルシューティングのためのシステム理解や自動化のためのコーディング技術といったものが必要とされます。
今回はインフラ担当者としてシステム運用の効率化に一役買ったという一例を紹介します。
システムの概要と問題点
今回の対象システムの特徴は下記です。
- 利用者ごとに設定の異なるサービスプロセスが多数動いている
- 各サービスの管理者は申請システムよりサービスの設定変更を依頼する
- サービスの運用担当者（私たち）は申請システムから送信される設定変更依頼メールを参照し、設定変更を実施する
図にするとこんな感じです。
従来はメールを受信したら運用担当者が手動で設定変更コマンドを実行し、設定変更を行っていました。
ですが、ときに設定変更作業は「別の作業に合わせて◯時に実行してほしい」や「休日に実行してほしい」など、担当者が手作業で実施するには辛い条件をお願いされたり、一日に多数の依頼が来て大変なことも…
問題の解決
ということで、この運用プロセスを自動化してしまおうという計画が立ち上がりました。
下記の特徴を活かせばうまく自動化ができそうです。
- 設定変更作業はWeb APIで作業可能
- 設定変更依頼メールはシステムから送信されるためフォーマットが決まっている
どう対応する？
設定変更作業はWeb APIで作業可能
つまり、Web APIを叩くプログラムを開発してネットワークをうまくつなげれば設定変更作業は自動化できそうです。
対象システムと同AWSアカウント上にLambdaを設定し、そこでプログラムを動かすことにしたのでネットワークの構成は比較的容易に行えたと思います。
「Web APIを叩くプログラムを開発」とさらっと書きましたが、手作業で人の目を介してやっていたこと（特にエラーハンドリング）をプログラムとして実装するのはかなり大変でした。
システムの規模が大きくなるほど作業の自動化というものがテーマに上がることが増えると思うので、運用担当者にも高度なプログラミングスキルが要求されることも増えていきそうですね。
設定変更依頼メールのフォーマットが決まっている
従来は人がメールを受信して、それが作業開始の起点となっていました。
自動化にあたり、プログラムがメールを受信して、その内容をもとに動作を開始する（いわゆるトリガ）となるように設計する必要があります。
前述のとおり、設定変更依頼メールはシステムから送信されるため、フォーマットが決まっていました。
よって、プログラムがメールを受信して内容を読めればよさそうです。
これにはAmazon SESを使うことにしました。
SESではメールが受信できるので、プログラムにSESをとおしてメールを受信させることができます。
システム構成
ということでこんな構成のシステムができました。
サーバレスな構成となりました。
当時はまだ周囲にAWS Serverless Application Model (AWS SAM)の知見が少なかったので、フレームワークとしてServerless Frameworkを採用しています。
（今ではAWS SAMを使う案件もどんどん増えてきています。）
DynamoDBには申請内容をパラメータ化して格納し、処理フラグを付けています。
設定変更を実行するLambdaは処理フラグが「未処理」にあたるレコードを探し、該当するものがあればパラメータに沿って設定変更を行う仕組みとしています。
さて、お気づきでしょうか
実はこのシステム、ベストプラクティスとは言えない点が…
DynamoDBの使い方は適切なのか
DynamoDBはNoSQL型のデータベースです。
キーを指定してレコードを取得するということが得意ですが、今回求められている "処理フラグが「未処理」にあたるレコードを探す" という動作はあまり得意ではありません。
（この記事で少し触れています。特定のカラムの値を指定してレコードを取得するのはRDBの方が得意です。）
また、動作に問題があったときに追えるようにとの意図でデータベースに申請内容を格納していますが、それ以外に申請内容を参照することはなく、わざわざデータベースを採用する必要もなさそうです。
DynamoDBをSQSに置き換える
「動作に問題があったときに追えるように」ということで、よくよく考えてみるとLambdaの動作ログに動作時に読み込んだ申請内容を出力しておけばCloudWatch Logsから追うことは容易なのでデータベースにデータをためておく必要はないと気付きました。
そのためDynamoDBは廃止し、Amazon SQSを使ってデータをLambdaに渡す構成に変更しました。
いかがでしょうか。より無駄のない構成にできたかと思います。
自動化の効果について
自動化によりこんな効果がありました。
運用担当者の設定変更作業の負担が減った（ほぼゼロになった）
運用担当者は都度メールを確認して申請状況をチェック、申請があれば作業予定を整理して作業者を調整し、作業予定時間がきたら40分ほどかけて作業を行っていました。
また、作業者に欠員が出た場合は臨機応変に代わりの作業者を割り当てる必要もありました。
自動化後はこれらの負担が全部なくなりました。
プログラムのエラー発生時のみ対応は必要ですが作業内容自体はシンプルなものでエラーが起こることは少なく、この作業に関する運用担当者の負担はほぼ無くなったといって良いでしょう。
管理者が気兼ねなく申請できるようになった
実はこのシステム、管理者の中には海外拠点の方もいました。
設定変更作業は日本拠点の担当者が行うため、時差によって申請を出してから作業までのタイムラグが長かったり、日本時間の休日夜間に実施を依頼することになる場合は気を遣う必要があったり…
自動化されると作業時間を気にすることなく気軽に申請できるようになったようで、時間を問わず依頼が来るようになりました。
利用者の待ち時間が減った
自動化によって、設定変更にかかる時間が従来の約40分から5分以内に大きく短縮されました。
作業時間中はサービスが停止するのですが、その時間が短くなったので、利用者からは非常に喜ばれています。
正直、自分達が楽するために行なった自動化なので、利用者視点の効果は考えていなかったのですが、使う側から見ればたしかにうれしいよなぁと。
結果的にユーザ満足度が上がった形になり、システムの品質としても高くなったと言えるでしょう。
まとめ
システムの規模が大きくなったり、利用頻度が上がると、運用負荷は大きくなってきます。
定型作業や単純作業は自動化を検討し、より効率的な運用を目指していくことがシステムの品質をあげるうえで重要となってきます。
AWSのサービスは相互に連携させることが容易で、今回のようにうまく組み合わせることで一見複雑なことも意外とできてしまうので、面倒だと思う作業があれば一度自動化できないかと考えてみることをおすすめします。
あと、やっぱりプログラミングスキルは大事ですね。
