【運用管理】 AWSの運用はどこまでラクできる？運用自動化サービスをまとめて解説！

セッションは「AWSはなにをどう自動化できるの？」と具体的な話に入る前に、そもそも「自動化によって解決できる運用の課題はなにか」という話からはじまりました。繰り返しますが、自動化は「なんでもうまくいく魔法のツール」ではないので、どういう課題に向いているのかをきちんと把握することが最初の一歩になります。このセッションではQCD（Quality、Cost、Delivery）の観点から、下図のように整理していました。

つまり、手作業での運用だとオペレーションミスは当然起きる可能性があるし、ずーーっと見張っていない限り、トラブルが起きてもすぐには気づけないし、だれかがずーーっと監視するとなると相当なコストになります。

これを自動化すると、基本的にオペレーションミスの可能性はほぼなくなり、自動で監視しているのでなにかあればすぐに見つけられます。そして同じことを繰り返すのが自動化の得意分野ですから、「なにかを監視し続ける」とか「あるイベントが発生したら、この対処をおこなう」とか、定型的な作業を任せることで、その分の人的コストが削減できる、というワケですね。

こう聞くと、割と当たり前のことのように思えますし、そういう作業もたくさんありそう。じゃんじゃん自動化すればよいのでは？という気持ちになりますが、ここで忘れてはいけないポイントとして注意喚起されていたのが「自動化すること自体にも、コストがかかる」ということ。言われてみればそりゃそうです。だからこそ、すべてを自動化するのではなく、なにを自動化するのかをきっちり選ぶことが大切なのだそう。

特に自動化に向いているのは、「単純作業であり」「手順が固まっていて」「繰り返し発生する」作業。条件や場合によって手順が変わったり、1回しかやらないような作業は自動化には向きません（これも当たり前といえば、当たり前ですよね）。じゃあ、それっていったいどんな作業なのか。そしてどの作業ならAWSで簡単に自動化できるのか。具体的なサービスの話に続きます！

まず紹介するのがAWS Systems Manager（SSM）。サーバの設定や管理、運用をまとめてできるサービスです。なにが便利かというと、これ、「SSMエージェント」というエージェントをサーバにインストールする必要があるものの、EC2インスタンスとオンプレミスのサーバのどちらにも対応していて、まとめて管理できちゃうのだとか。AWS、オンプレのサーバまで面倒見てくれるって！

AWS側のサーバのOSバージョンがなんだったか、オンプレ側のサーバのOSバージョンがなんだったか、どこにどのアプリケーションが入っているのか、この辺、Excelで管理してるよ……ってケースも多そうです。それ、全部自動化できますよ、ということ。SSMエージェントがサーバの構成情報（インベントリ情報）を自動で集めてきてくれて、最終的にはCSVで出してExcelでチェックできます。これは便利！

さらに、「毎週金曜の夜にサーバを停止、月曜朝に起動して、コストを削減したい（従量課金ですから）」という場合、1台ならまだしも、サーバがたくさんあったら結構大変。しかも起動し忘れたら、システムが使えないとか大騒ぎになりますし、停止し忘れたらし忘れたで地味に落ち込みそうです。これも、SSMを利用し、「SSMドキュメント」という形で定義すればOK。定義済みのSSMドキュメントもたくさん用意されていまして（EC2インスタンスの停止ももちろんあります！）、これらを組み合わせるだけで簡単に自動化できる、ということでした。

SSMがサーバ管理だったのに対して、AWSの「リソース管理」を自動化できるのがAWS Configです。AWSリソースとは、S3のバケットや、EC2インスタンスなどAWS上に自分が作成したもののことを指します。こういったAWSリソースにはひとつずつ公開・非公開などの設定をできるので、それを「だれが・いつ・どう変更したのかの履歴を記録」し、「望ましくない変更ならばもとに戻す」ことを自動化できるのがAWS Configです。

たとえば、あるS3のバケットを非公開設定にしていたのに、だれかが勝手に公開に変更してしまった。これを記録・検知し、自動で元の非公開設定に戻すことができます。しかも、こういったルールは、AWSが80個以上のルールを提供しているので、それを使えばOK（もちろん自分でイチからカスタマイズすることもできます）。ソースコードを書く必要もありません。

S3バケットの公開設定とか、人手で監視してチェックしてもとに戻すとなると、相当な手間がかかります。正直、現実的ではない。せいぜい、管理画面でたまたま見たときに気づく人がいたらラッキー、レベルです。とはいえ、いつの間にかS3バケットが公開されていたとか、恐ろしくて考えたくもない。これ、自動化できるならば嬉しいポイントでしょう。

さらに、リソースに対する変更に限らず、なにかしらの“イベント”に対して処理を実行できるのが「Amazon CloudWatch Events」です。検知する対象（ターゲット）は、AWS IAMやAmazon EC2などを設定でき、これらのターゲットでなんらかのイベントが発生した際に、ルールに従ってAWS Lambda（詳しくは過去コラム『「Lambda」ってなにがスゴイんですか？』で解説しています）やAmazon SNS（メールやSMSなどに通知できるメッセージングサービス）に処理を渡すのが基本的な流れです。つまり、たとえば、だれかが勝手にAWS IAMでアクセス権限を変更したことを検知し、メールで通知する、といったことが可能になります。

実はこれ、最初に紹介したSSMでも似たようなことができるらしいのですが、SSMはサーバ内にエージェントがあることが強みであり、「管理対象になにかしたいとき」に有効なのに対して、Amazon CloudWatch Eventsはイベントドリブンで実行できることが特長。なにかしらのイベントに反応して処理を実行したいときに使うといいのだそうです。正直、それで自分でうまいこと使い分けできるかは自信が持てませんが、頭の片隅に覚えておくとよさそうです。

セッションの最後は「運用の自動化は一度やって終わりではなく、発展を続けるプロセスである。繰り返しの多い単純作業からスタートして、自動化されていない作業へ徐々に範囲を広げていこう」というメッセージがありまして、一度自動化したらあとはなにもやらずに任せておけばいいのでは……という心の奥底にしまったはずの本音を突かれたようで胸が痛いです。もちろん自動化で作業負担を減らし、その分ほかの業務に集中することはメリットですが、一度やって放置ではなく、継続的に取り組んでいくことで、ますますそのメリットが大きくできる、ということでしょう。

さらに、「自動化」といっても「今までやっていたことを自動化する」だけではなく、「やった方がいい（けど今まで厳格にはやれていなかった）ことを自動化する」も多く含まれていると感じました。特にセキュリティの観点ではその方向性が強いように思います。

そして、RPAなどの話を聞いていても同じなのですが、いきなりなんでも全部自動化しようとするとうまくいかない、ということ。できるところから少しずつはじめていくのがよさそうです。
ちなみに、ソニービズネットワークスが提供するAWS導入・運用支援サービス「マネージドクラウド with AWS」では、独自の管理画面「クラウドポータル」を標準で利用できます。クラウドポータルではSSMによる自動化をもっと簡単に使える機能も用意しています。詳しくはクラウドポータル開発者の方にインタビューした「サーバのOSアップデートが面倒すぎるから、簡単にできる機能を開発しました」をご覧ください！
以上、シイノキでした。