JAWS-UG中国・四国勉強会レポート 第8回

AWSJ藤原さんが運用自動化のポイントをわかりやすく解説

構成はElastic Beanstalk、監視はCloudWatchを賢く使おう

第7回となるJAWS-UG岡山勉強会の前半は、AWS Elastic Beanstalkを使った自動化の話が3連発。複数サーバーの運用に携わったこともなく、AWSの機能を試すにもGUIのManagement Consoleからしかサービスを起動したことのない筆者にとっては理解の難しいセッションが続いた。しかしさすがは中の人。AWS ソリューションアーキテクトの藤原 吉規さんはわかりやすくElastic Beanstalkの概要を説明してくれた。セッション後半では運用自動化に欠かせないCloudWatchを使った監視手法の解説もあった。

前半は難波さんを皮切りに3人続けてElastic Beanstalkによる自動化の話

　しょっぱなから2セッション続けてElastic Beanstalkの話を聞き、テクニカルな部分に理解が及ばず、筆者の脳みそは水を吸いすぎたスポンジのようになっていた。もうこれ以上何も吸収できそうにない。そこに颯爽と現れたのが、3セッション目を担当するAWSの藤原さんだ。「実務で役立つAWS活用方法」というセッションタイトルだが、またしてもいきなりElastic Beanstalkの話。

「Elastic Beanstalkとは何かというと、インフラの構成や構築、デプロイを自動化のしてくれるサービスをです。提供されているテンプレートからデプロイすることもできるし、カスタム構成を作ることもできます。Elastic Beanstalk自体は無料で利用できますが、それによって起動されるリソースに課金されます」（藤原さん）

またしてもElastic Beanstalkの話か！と筆者を居絶望にたたき落としたスライド

　うん。そのくらいのことまでは理解したつもり。しかしその先が問題なんだよ、と視界がくらみ始めた筆者。

「前半のおふたりはコツコツとebextentionsを書いていましたが、もう少し簡単な方法があります。必要なものをManagement Consoleから構築して設定ファイルに書き出し、zipアーカイブにしてアップロードすれば、Elastic Beanstalkがデプロイしてくれます」（藤原さん）

AWS 西日本担当 ソリューションアーキテクト 藤原 吉規さん

　あれ？ わかる。GUIでしかAWSを使えない筆者にもわかるよ、これなら！ そっか、CLIでガリガリいじらなくても、Elastic Beanstalkは使えるんだ。しかも、更新してみて問題が発生した場合には、その場でロールバックもできるらしい。検証環境では動いたけど本番環境では動かなかった、なんてときにもすぐに一手戻せるってことだから、手動で構築して運用管理するよりずっと安心感がある。

「サーバーが1台だけならそれほど大変ではありませんが、オートスケーリングしたい場合や、障害時に再起動したい場合には、サーバーに書き出されているログが消えてしまうという問題があります。これを解決するためには、CloudWatch Logsを使ってください。さっきまでCLIでガリガリやっていたのをみて不安になった方も安心してください。CloudWatchはManagement Consoleから設定ファイルできますから」（藤原さん）

GUIからでもElastic Beanstalkは使えるんだ！

　見透かされたような説明にどきっとしつつも、やっとわかる話になってひと安心だ。CloudWatch Logsには1日1回S3にログを保存する機能などもあるとのこと。さらに、オートスケーリングの設定もGUIでできるとわかった。時間を設定し、そのときに動かしておきたい最小構成と最大構成を設定すれば、自動的にスケールしてくれる。自社製品がテレビ番組で取り上げられることがわかっていれば、その時間に合わせてスケールアップを予約しておくことができるわけだ。1回限りの予約ではなく、繰り返し設定も可能。

　と、この解説をしているときに会場のあちこちから声が上がった。

「オートスケーリングの予約、UTC時刻でやらないといけないんですね」

ポップアップ画面の一番下、日時設定欄の右に示された「UTC」の文字を参加者は見逃さなかった

　確かに、画面には「UTC」の文字があり、ローカルタイムに変更するようなボタンは見当たらない。ただし、設定後にオートスケールスケジュールを一覧表示する画面では、JSTに表示変更できる。この画面で最終確認をすれば、間違いは防げそうだ。

休憩を挟んで後半は、CloudWatchを使った監視の全容へ

　構成、構築を自動化して運用を助けるのがElastic Beanstalkなら、CloudWatchは監視と障害対応を自動化して運用を助ける機能と言える。しかしオンプレミスの時代から監視製品は数多くあり、今も使われている。なぜCloudWatchを使うべきなのか。

「クラウドでは、サーバーを監視メトリックスするのではなく、サービスを監視しなければなりません。監視メトリックスも変わってきました。CloudWatch はAWSの各種サービスを監視するマネージドサービスで、セットアップ不要で使えるうえにオートスケーリングなどのアクションを起こすことも可能です」（藤原さん）

サーバーを監視するのではなくサービスを監視し、障害対応してくれるのがCloudWatchだ

　CloudWatchには大きく3つの機能がある。CloudWatchの基本機能はシステム監視とリソース利用状況の可視化だ。標準メトリックスで取得できない情報も、カスタムメトリックスを設定することで収集できる。障害が見つかれば正常な状態に合うようにサービスを自動的に再起動するなど、モニタリングからアクションを起こすことでシステムを正常な状態に保つことができる。

　CloudWatch Logsは、AWSサービスに特化したログ管理プラットフォーム。EC2などにエージェントをインストールすることで、ログを集中管理できる。Elastic Beanstalkで立ち上げたサービスにはあらかじめエージェントがセットされているので、Elastic Beanstalkを使うならCloudWatchで運用監視すべきというのがAWSの基本思想なのだろう。

　CloudWatch Eventsは、イベントをトリガーにアクションを実行する機能。負荷が指定した値よりも高まったらサーバーを増やしたり、トリガーとして時刻を指定すればcronのようにも使える。

CloudWatch Eventsを使えばさまざまなトリガーからアクションを実行させることができる

「クラウドになってから運用監視の考え方自体が変わってきています。以前はサーバーやサービスの死活監視を行なうために、監視製品からサーバーにアクセスして情報をPollingしていました。しかし構成が動的に変わるクラウドでは逆に、サーバーからPush型でログを送りつけるという手法を取らなければなりません」（藤原さん）

クラウド化に伴い、監視メトリックス自体がPollingからPushへと変わってきた

　つまりオンプレミスにはオンプレミスの監視ソリューションを、クラウドにはクラウドの監視ソリューションを使うべきということ。旧来の考え方を捨て、構成や構築も、運用監視も、マネージドサービスを活用しようね。

■関連サイト

• JAWS-UG岡山（Doorkeeper）