はじめに

こんにちは。NTTテクノクロスの青木(AWS社内研修講師)です。
今回も引き続き、AWS関連の道場研修について、ご紹介致します。

道場研修とは

開発現場で活躍するプロフェッショナル社員を講師とした実践型の技術者育成組織で、実務経験豊富な当社プロフェッショナル社員の実践経験から得られたノウハウを用いて社員自ら研修コンテンツを作成し、全社員の技術力向上に貢献しています。
道場のカリキュラムや講師紹介等はこちらをご覧ください。

AWS関連の道場研修のご紹介

道場が主催するAWS研修は、難易度別に以下の2つを実施しています。
※応募人数により開催可否、回数が決定されます。

• AWS入門編 (1日コース、年2回開催予定)
  目的：スタートアップで押さえておきたいAWSの基本サービスを学ぶ。
• AWSトレーサビリティ＆ログ可視化ハンズオン (1日コース、年1回開催予定)
  目的：AWS利用におけるアクセスログの管理方法を学ぶ。

今回は「AWSトレーサビリティ＆ログ可視化ハンズオン」をご紹介致します。

本研修の概要

本研修はシステム維持管理における「運用」に着目し、下記の3本立てとしました。

• ユースケース1：操作ログの可視化
• ユースケース2：アプリケーションデプロイ効率化
• 自由課題(Tips紹介や、各PJでの課題相談など)

入門編と同様「クラウドは手を動かしてこそ！」という意味合いも込め、ハンズオンの時間配分を全体の8割近くに設定し、受講生が自分のペースでどんどん手を動かせるように配慮しました。また、ハンズオンで構築するWebアプリケーションは講師陣が予め準備し、ログ管理部分に作業集中出来るようにもしました。

ハンズオンカリキュラム検討

様々な案件に携わることで、システムの維持管理において以下を要件とするお客様が多いことがわかりました。

• サーバOSに対するログイン履歴やアクセス履歴を取得して、一定期間保存すること。
• アプリケーションに対しても同様に管理し、ログイン履歴やアクセス履歴を取得して、一定期間保存すること。
• 必要に応じ、当該ログを確認できること。

これらを踏まえ、本研修のログ管理のスコープは「AWSリソース操作」と「アプリケーションログ」とし、ハンズオンについてはログを 蓄積 する仕組みの確立だけでなく、 可視化 する仕組みについても受講生に経験してもらうことを意識したシナリオとしました。さらに、 AWSのサービスを使って効率的に実施する ことも目指します。

本研修で利用するAWSサービスは以下になります。

• 「ユースケース1：操作ログの可視化」で主に利用するサービス
  • CloudTrail
  • S3
  • CloudWatch(Logs)
  • lambda
  • Elasticsearch Service(以降ES)
• 「ユースケース2：アプリケーションデプロイ効率化」で主に利用するサービス
  • VPC
  • EC2
  • RDS
  • Route53

それでは次章よりそれぞれのユースケースについてご説明致します。

ユースケース1：操作ログの可視化

当ケースで管理対象とするログは、AWSならではである「AWSリソース操作により生じるログ」としました。 まず、ログのライフサイクルについてまとめると以下のフローになります。

ここで重要になるのは以下3点であり、それぞれの実現ポリシーを検討致しました。

1. 証跡情報の監視を短時間に実現できること
2. 長期間にわたって稼働をかけずに運用できること
3. 低コストでデータ消失の心配なく実現できること

1.および2.については「AWSのマネージドサービスを利用する」こととし、3. については、「99.999999999% の耐久性であるオブジェクトストレージのS3を利用すること」としました。

ハンズオンでは、下図のようにAWSのリソース操作ログを(ESで利用可能な)Kibanaで可視化する一連の動作を実践頂きました。

環境準備におけるマニアックな考慮事項のご紹介

受講者への環境提供は、ソフト道場が所有する1つのAWSアカウントで実施致しました。
研修環境準備の過程で「検討しておいてよかった！」と思うマニアックな考慮事項をご紹介しようと思います。

CloudTrailのリージョンごとの追跡情報は5つまでであり、この制限を緩和することはできないこと。

本研修では最大16名の同時受講を可能としています。特に意識しなければ全員Tokyoリージョンを使ってもらいたいところですが、上記制限のため受講者ごとに複数リージョンを割り当てるようにしました。その他のCloudTrailの制限については公式ドキュメント をご参照下さい。

新規サービスは、GA(General Availability)時に全てのリージョンで利用可能であるとは限らないこと。

研修当時はまだESが一部のリージョンでのみ利用可能という状況でした。
この2つの考慮事項から、受講生数名ごとにリージョンを割り当て(4人ずつVirginia、Seoulのように)、 未割り当てなリージョンも確認 して本番に備えました。

予備の重要性に気付かされることに・・・

事前に 通し稽古 を行うなど受講生のロールプレイを重ねたのですが、本番当日、とあるリージョンで接続不良が発生し一部の受講生がテキスト通りには進められなくなる事態が発生してしまいました。直ちにサポートに問い合わせるとともに、事前に調べておいた予備のリージョンを代わりに使ってもらうなど臨機応変に対応することでその場を乗り越えることができました。事前準備、予備の確保って大事ですね。。。

ユースケース2：アプリケーションデプロイ効率化

ユースケース1では、AWSのリソース操作におけるログの蓄積、可視化について実施しました。では、アプリケーションのログ蓄積についてはどのように下準備をすれば効率的に実施できるでしょうか。その1例を研修シナリオと共にご紹介致します。

初期設定と言ってもいろいろある

Launch直後のEC2に対して、環境適用のためにアプリケーション管理者が実施すべき作業は以下が考えられます。

• 環境の初期化
• クラスタ構成の設定
• アプリケーションの(再)デプロイ
• RDSのエンドポイントの設定
• 環境変数の設定
• ログ出力の設定

ハンズオンでは、"AWSならでは"な機能を経験頂くため、以下のシナリオを用意しました。
1.および2.でアプリケーションデプロイの効率化を行い、その結果確認を3.で実施するシナリオです。

1. Private Hosted ZoneによるDB指定
2. awslogsエージェントによるログ収集とcloud-init
3. アプリケーションのアクセスログをESで可視化

1. Private Hosted ZoneによるDB指定

運用稼働を削減するため、可能な限りAWSマネージドなサービスを選択します。その代表的なサービスと言っても過言ではないくらい有名なデータベースサービスがRDSです。

RDSのエンドポイントはFQDNで払い出されますが、それをそのままアプリケーションのAMIに仕込んでしまうと、AMIでDBの接続先を保持してしまうため、RDSのエンドポイントが異なる環境(開発/検証/本番など)では、AMIを複数保持しなければなりません。(管理が非常に手間です！)

それを回避するため、Route53のPrivate Hosted Zoneを活用し、アプリケーションのDB接続情報はそのままに、解決先の名前を変更することで、AMIの管理数を削減することが出来ます！(なんて便利！)

2. awslogsエージェントによるログ収集とcloud-init

• awslogsエージェントとは

AWSがオフィシャルに提供するEC2インスタンスから CloudWatch Logs に任意のログを流すためのツールです。インストールすることでserviceとして動作させることができます。インストール手順については公式ドキュメントをご参照下さい。

• cloud-initとは

インスタンス起動後の初期化処理を仕込むOSS製品で、AmazonLinux等には予め導入されており、EC2インスタンス作成時のUser-Data実行にも使われます。

ハンズオンで目指す構成

1. サンプルWebアプリケーション(接続先DB情報含む)とawslogsエージェント等の初期設定を済ませたAMIを作成する。
2. 1.で作成したAMIをLaunchし、cloud-initにより以下を取得し、CloudWatch Logsのロググループ名を自動修正します。
   • 自身が稼動するリージョン名
   • 自身のインスタンスID
   • 自身のNameTag
3. CloudWatch Logsへの送信対象は、ハンズオンでは以下の2ファイルとしてますので、その送信状況を確認します。
   • catalina.out
   • localhost_access_log.txt

3. アプリケーションのアクセスログをESで可視化

アプリケーションデプロイがうまくいったことを確認します。
CloudWatch LogsとESとの連携はスムーズに実施できる状況にありますので、マネージメントコンソールから簡単に実施する事ができます。
CloudWatch Logsから対象のロググループを選択し、[アクション]から[Amazon Elasticsearch Serviceへのストリーミング開始]を選択します。
その後ESクラスタとサブスクリプションフィルタのパターンを指定すればLambda Functionによりデータの蓄積が開始されます。
あとは、予め講師陣が用意しておいたサンプルダッシュボードのjsonファイルをKibana3でImportすれば、可視化完了です。

おわりに

1日の研修を通じて大きく以下の2点を受講生には体験して頂けたかと思います。

1. 管理すべき対象のログは「アプリケーションやOSの出力するログ」だけでなく「AWSのリソース操作」も対象であること。
2. ログは蓄積するだけでなく管理(可視化)すること。

本研修の目的である「AWS利用におけるアクセスログの管理方法を学ぶ」は達成でき、業務で活用して頂けましたら幸いです。

おまけ

次回研修に向けた挑戦課題を記載します。

• ログの可視化におけるKibanaの最新版対応。

研修当時は、AWSがサンプルダッシュボードを提供してくれていたのはKibana3でした。最新バージョンに対応するよう計画しています。