【運用管理】 クラウドネイティブなシステムの運用監視では、考え方も指標も変わる！

運用管理系のセッションで一貫して主張していたのが、「AWSならアジリティとガバナンスを両立できる」というメッセージでした。
そもそもシステム運用において重要なのが、変化に柔軟かつスピーディに対応できる「アジリティ」と、ルールに則りリスクを最小限に統一した運用をおこなう「ガバナンス」の2つの軸です。
しかし、一般的にこの2つはトレードオフになりがち。スピーディな対応をするにはある程度リスクを許容しなければならず、ガバナンスを徹底するとスピードが落ちてしまう、というのはよく聞く話です。

AWSには、運用や監視をおこなうサービスもかなりたくさんあります。ありすぎて分からないくらいあります。それらをうまく活用することで、ガバナンスを維持しながら、スピーディに変化に対応する（アジリティの高い）システムを実現できる、というワケです。

そもそもクラウドネイティブなシステムとは、サーバーレス（AWS Lambdaを使うヤツですね）やフルマネージドで運用をAWSにお任せできるサービスをうまく活用した環境のこと。これらを使いこなすことで、“本当に業務に必要な処理の開発”や“自社に特化した対応”などにフォーカスできるようになりますし、よりコンパクトにシステムをリリースできるようになります。

つまり、アジリティが高まるということ。ただし、当然これまでとはシステムの構成も変わります。この環境に対応するには、運用にもクラウドネイティブな要素を取り入れる必要がある、というわけですね。

そしてもうひとつ大切なのが「Operational Excellence」という考え方です。経営一般で使われるものですが、AWSのベストプラクティスをまとめた「AWS Well Architected Framework」のなかでは「ビジネス価値を提供するためのシステムの実行とモニタリング、および継続的にプロセスと手順を改善すること」

と定義されているそうです。思わず身構えたくなる文章ですが、ポイントは「ビジネス価値を提供する」と「継続的に改善する」の2カ所。システムが正常に動いているかどうかの観点だけでなく、ビジネスとして問題ないパフォーマンスが出ているかなど、よりビジネスにフォーカスした運用をおこない、そして定期的に運用を見直して改善し続けよう、ということです。

継続的な改善が大事だということは分かります。クラウドにあわせた運用がいいのも分かります。じゃあ、どこから変えればいいのでしょうか？「クラウドにあわせた運用」ってどんなものなんでしょうか？従来（オンプレミス）の感覚で「システムが健全化どうか」を監視しようとすると、インスタンスの死活やCPU・メモリの使用率などを見ることが多いでしょう。オンプレミスではリソースも限られており、リソース1つずつの正常・異常がシステムの健全性に直結するので、これらを監視するのは妥当でした。

ですが、クラウドでは負荷にあわせてリソースを簡単に増減できますよね。自動的にリソースを調整するAWS Auto Scalingなどもあり、リソース単体を監視していても、状況はどんどん変わっていきます。だから、クラウド環境では「リソースひとつずつ」ではなく、「特定のリソースに依存しない指標」にシフトすることが重要になるのだそう。システムのスループットやレスポンスタイムなどよりシステム全体の状況を示していて、ビジネスに影響があるものを指標として設定するとよいのだそうです。

たとえば「どのくらいでページが表示されるか」とか「1分間に何件くらい処理できるか」とか、ビジネスに直結する指標を持っていれば、ビジネス側の担当者とも状況を共有しやすくなりますし、改善にもつながるのでは……という理想像があるようです。

さて、システム全体のパフォーマンスなどを指標に定め、監視するとして、なにを使って監視するのかというと「Amazon CloudWatch」です。以前のコラム『AWSの監視ツール「CloudWatch」で何ができるの？』でも取り上げましたが、そのときにはAWS環境のCPUやメモリといったリソースも簡単に監視できる、として紹介していました。

Amazon CloudWatchはもちろんリソースの監視もできますが、「ロードバランサがどれくらいのリクエストを処理しているか」とか「APIがどれくらいのレスポンスタイムなのか」といった、システム全体に直結する指標の監視も標準で対応しているとのこと。
複数のインスタンスをAWS Auto Scalingでスケールさせているときにも個々のリソースではなく、全体のリソースの平均的なCPU使用率をチェックしたりもできるそう。当然と言えば当然ですが「クラウドネイティブな運用監視」が簡単に実現できる、というワケです。

さらに、「Amazon CloudWatch ダッシュボード」というものが提供されていまして、これを使うとAWSリソースのさまざまな情報をまとめて確認できるのだとか。まずは全体を確認してから、どこを重点的に監視すべきかを絞り込んでいくのにも使えそうです。
そして、Amazon CloudWatchの強みはなんといってもほかのサービスと連携しやすいこと。その筆頭に挙がるのが、ログの検索・分析をおこなうサービス「Elasticsearch」を簡単に使えちゃうマネージド型サービス「Amazon Elasticsearch Service」です。

とにかくログを貯めて監視できる「Amazon CloudWatch Logs」（こちらも前回のコラムで解説しています！）にログを貯めておけば、コンソールからワンクリックでAmazon Elasticsearch Serviceに連携できちゃいます。そうすれば、ビジュアル化ツール「Kibana」でグラフ化したり、条件で絞り込んで、傾向を分析したり……といったことも簡単にできるようになります。
初心者的は、果てしなく道のりが長い気がしてなりませんが、「ツールが揃っていて」「連携する仕組みも用意されている」というのは心強いところのように思います。

もうひとつ、ガバナンスとアジリティを両立するクラウドネイティブな運用において、大切になるのが「システムのデプロイを自動化する」ということ。本番環境へのデプロイ、実は手作業でやってるんだよね、という企業も多いかもしれません。でも、アジリティを高めるということはつまり、デプロイの回数も増えるということ。「自動化を進めることで、変化の繰り返しに強くなろう」ということですね。
そして「ビジネスの要望に応えてスピーディに対応する」となると、「試しにやってみて、ダメならもとに戻す」という実験的な施策も多くなってきます。ですから、できるだけ小さく本番化して、すぐに切り戻せるようにすることがポイント。

これ、手作業でやるとなったら、相当面倒ですよね。っていうか正直そんなことやりたくない。でも大丈夫。AWSにはこういった管理をまとめて自動化する「AWS Cloud Formation」があります。「AWS Cloud Formation」がインフラ全般、リソース全般を管理できるのに対して、アプリケーションのデプロイ・ロールバックを管理できるのが「AWS Elastic Beanstalk」。さらにAWS開発者ツール（Developer Tools）として、開発環境やテスト・ビルド管理ツールなどのツールもひと通り揃っています。
つまり、これらを使えば！専用のインフラを用意することなく、アプリケーションの開発から、パッケージの管理、デプロイやロールバックの自動化まで、まとめて実現できるというワケです。

……と、ここまではクラウドネイティブなAWS運用の理想像をお伝えしてきたわけですが、いきなりここまでできるかというと難しいのも現実でしょう。
オンプレミスからクラウドに移行するからといって、いきなりサーバーレスやマネージドサービスをフルに使ったクラウドネイティブな環境になるわけではないですし、AWS Auto Scalingを使えるシステムばかりじゃありません。とりあえずリソースの使用率を見ながら、手作業でリソース追加する……という運用も少なくないかと思います。

セッションでも、いきなり理想形を目指すのではなく、使えるところから使って「継続的な改善」（最初に出てきたワードですね）をしながら、クラウドに適した運用に近づけていきましょう、といったメッセージでまとめられていました。とはいえ、改善をするためにもまずは現状を知ることから。性能の基準やチームの体制、システムの健全性維持にかかるコストまで確認しましょう、とのこと。その辺のチェック項目が網羅されているのが「AWS Well-Architected Tool」。一度自社の運用体制をチェックしてみるのもいいかもしれません。

運用監視というと、これまでは「システムをいかに止めないか」という観点が強く、トラブルが起きないように対処することが中心のように思っていました。それはそれでもちろん大切な要素ではありますが、これからは「いかにビジネスに価値をもたらすか」まで意識した運用が求められる、ということでしょう。それだけITやシステムがビジネスにおいて重要になってきた証拠なのでしょうが、それはまたそれで大変そうと思ったり思わなかったり……。
次回も引き続き、AWS Summitのセッションで学んだことをまとめていきたいと思います。以上、シイノキでした！