【セッションレポート】『ログからひも解く、AWSのす・べ・て!!』 #cmdevio2015E
Eトラックの1本目は、 『ログからひも解く、AWSのす・べ・て!!』というタイトルで、アマゾン データ サービス ジャパン株式会社酒徳知明様、関山宜孝様にお話いただきました。
ひとくちにログと言っても、Apacheなどのミドルウェアで記録するログ、アプリケーションで記録するログなど様々なログがあります。 AWSであっても、Amazon RDSやElastic Load Balancingなどのサービスが記録するログがあります。 一方で、AWSの特徴的なロギングサービスとして、Management ConsoleなどでAWSのリソースを変更した時などにログを取得するAWS CloudTrailがあります。 今回のセッションでは、AWS CloudTrailの活用方法を中心に、最近追加されたAWS Configに関するトピックをお話いただきました。
当日のスライドはこちらからダウンロード願います。
AWS CloudTrail活用のベストプラクティス
システムのAWSへの移行、特にオンプレやハイブリットからの移行の時、ロギングをどのように運用していくかはひとつの課題です。 はじめに、ロギングの運用に関して要点や運用パターンを紹介していただきました。
リソースの拡大・縮退を記録するワケ
AWSをはじめとしたクラウドサービスの大きな特徴は、リソースが必要に応じて拡張・縮退することです。 Auto Scalingのようにインスタンスを自動的に拡張・縮退するサービスは解りやすいですが、それ以外でも重要です。 AWSでは、ハードウェアに束縛されないことから、リソースを拡張・縮退させやすいため、検証用に一時的なインスタンスを立ち上げたりと、思った以上にリソースが拡張・縮退するのです。
インスタンスが追加されれば金額は小さくともコストは発生します。 「インスタンスを作成する」ことは、オンプレでいえば「ハードウェアを調達する」こと変わらないコトです。 したがって、『調達の記録を取り、必要に応じて参照できるようにする』というのは当然の要求でしょう。
APIによるリソース管理とAWS CloudTrail
AWSではインスタンスの作成だけでなく、ほとんどの操作はAPIを通じて行います。 APIを利用するという点は、コマンドラインツールなどから実行した場合だけでなく、Javaなどのライブラリから実行した場合も、Management Consoleから実行した場合も同様です。
このAPIによるAWSの操作のログを取得するサービスがAWS CloudTrailです。 言い換えれば、AWSのリソースを、「何時、誰が、どのように操作したか」を記録します。
また、Management Consoleにログインする操作など、API経由ではない操作についても、記録されます。
AWS CloudTrailの活用
AWS CloudTrailでAPI操作のログを保存するだけでも、トラブルが発生した時に役立ちます。 ですが、AWS CloudTrailには、様々な活用方法があります。 それらの活用方法を、短期視点・中期的視点・長期視点の3つの視点から解説されていました。
アラート(短期的視点)
AWS CloudTrailは、Amazon CloudWatch Logsと連携することで、問題となりえるAPI操作を早期にアラートとしてあげることができます。
例えば、特定サイズ以上のインスタンスが起動された場合、インスタンスが破棄された場合など、予定されないAPI操作がされたならば、なんらかのトラブルが発生している可能性があるでしょう。 そのようなAPI操作について監視を行い、アラートで通知を行うように設定すれば、トラブルも最小限の被害で解決できる可能性があります。
検索(中期的視点)
先日のアップデートで追加されたAWS CloudTrail - Lookupを使えば、直近7日間のAPI操作履歴を検索することができます。 これは、トラブルが発生した際の、ユーザが行う最初の調査となるでしょう。
検索した結果としてトラブルの原因が判明するかもしれません。 原因が解らない場合でも、そのログをAWSサポートに提供することで、問題の早期解決に繋がります。
可視化(長期的視点)
AWS CloudTrailのログは蓄積することで資産となります。 API操作の履歴により傾向などを分析し、利用価値が出てくるかもしれません。
とはいえ、JSONのログをそのまま解析するのは骨が折れてしまいます。 Amazon CloudSearch や Kibanaなどのツールを活用し、長期的視点でデータの可視化を行う例を紹介されていました。
リソースの状態を知るAWS Config
AWS CloudTrailのログは、いわばAPI操作の履歴です。 「何時、誰が、何を行ったか?」について記録されていますが、「今、AWSのリソースがどんな状態か?」を知ることはできません。 全てのログを順に追っていけば可能かも知れませんが、現実的ではありません。 また、あるEC2インスタンスがあったとして、そのインスタンスにどんなリソースが関連付いているのかを調べることは良くあります。
そんな要望に応えるべく、最近提供された機能がAWS Configです。 AWS Configを有効化することで、リソースの状態を取得したり、リソースの状態に変更があった時に変更内容を通知したりすることができるようになります。
また、AWS Configと連動したサードパーティ製ツールもあるようです。 構成内容を視覚化できるツールがあれば、運用や監視も便利になるでしょう。 個人的にはツールを作ってみたいですね。
なお、まだAWS ConfigではすべてのAWSリソースに対応しておらず、Tokyoリージョンでは利用できません。 現時点ではEC2やVPC回りなどを中心にサポートしているようですが、各サービスをサポートしていく予定とのことです。 また、イベント当日はTokyoリージョンで利用できませんでしたが、4/7に利用できるようになりました!(『AWS ConfigがTokyoリージョンに対応しました!!』)
AWSサポートからの視点で話すロギング
後半はAWSでサポートを担当している関山様より、サポートの観点からログについてお話いただきました。
AWSサポートとは
関山様が担当しているAWSサポートは、AWSの技術サポートを行う窓口です。 AWSサポートでは、サポートレベルとして、ベーシック、デベロッパー、ビジネス、エンタープライズの4段階があり、それぞれのレベルに応じたサポートを受けることができます。
なお、弊社のメンバーズに加入した場合、構築前のコンサルやAWSを使う上でのトラブルシュートなどを弊社で行います。 これは弊社がサービスを利用する側に特化してノウハウを持っているからです。 一方、AWS内部に問題がありそうな場合や、AWSサポートと連携して問題を解決しなければならないケースなどではAWSサポートと密に連携をとってお客様の問題解決に努めております。 サービスの提供側と利用側の違いですね。
AWS CloudTrailを有効化してください
「たったひとつの大切なこと」として関山様が話されていたことは、AWS CloudTrailを有効化するということです。
AWSではAWS CloudTrailはデフォルトで有効化されていません。 このため、何かトラブルが起きた後で原因を追跡しようとしても、ログがないため、調査に時間がかかってしまいます 。 したがって、トラブルの対応はできたとしても、原因は究明出来ないケースがあります。
AWS CloudTrailを有効化することで、AWS操作のほぼすべてがログとして残ります。 現時点で利用する予定はなくとも有効化しておけば、トラブル発生時に調査することが可能になります。 これは、AWSサポートに問い合わせる場合にも非常に重要な情報となります。 トラブル発生時のログが残っていることで、サポートの調査もスムーズに行うことができるからです。
AWS CloudTrailを利用する場合に発生するコストは、ログを保存するために必要なAmazon S3のストレージ料金とAmazon SNSと連携する場合はAmazon SNSの料金のみです。 月数十円から数百円程度のコストでしかないため、弊社で構築を行う場合でも、有効化を強くお勧めしています。
AWS CloudTrail Lookupによる簡単な調査
AWS CloudTrail Lookupは、つい数週間前にリリースしたAWS CloudTrailの新機能です。 Management Consoleから過去7日前までのAWS CloudTrailのログを検索することができます。
また、ユーザ名・イベントの種類・リソース種別・リソース名からログを絞り込むことができます。 勿論、期間でもログを絞り込めます。
例えば、インスタンスでトラブルが発生した時、インスタンスIDとおおよその時間が解れば、誰がどのような操作をAWSに対して行ったかを調査できるのです。 そのログをAWSサポートに提出すれば、迅速に原因究明ができることでしょう。 トラブル発生時の一次的な調査に重宝しますね。
なお、AWS CloudTrailのログは15分以内には保存されることになっています。 リアルタイムには記録されませんので、確認する場合は注意してください。
まとめ
何はともあれ、AWS CloudTrailを有効化するところからはじめましょう。 トラブルシューティングや適切なサポートに有効です。 既にAWS CloudTrailが有効になっているならば、アップデートされたAWS CloudTrail Lookupを試してみてください。
また、AWS Configは今後要チェックのサービスです。 構成情報などをまとめるツールは弊社でも幾つか自作していますが、これまではサービス毎にAWS CLIを利用して取得することがほとんどでした。 近い将来はAWS Congfigで簡単に情報を取得でき、これまでよりも深い情報をまとめることができるのではないかと期待しております。