この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
はじめに
中山（順）です。
こちらはAWS Summit Tokyo 2018で行われたセッション「Application Performance Management (APM) on AWS」のレポートです。
スピーカーは、アマゾン ウェブ サービス ジャパン株式会社 技術統括本部 ソリューションアーキテクトの畑史彦さんです。
概要
アプリケーション全体のパフォーマンスを把握することは、エンドユーザーの需要に合わせてワークロードを拡張できるようにする上では不可欠です。 また、ソフトウェアを継続的に改善しユーザー体験を向上することにも役立ちます。Amazon CloudWatch カスタムメトリクスのダッシュボードと AWS X-Ray を使用してアプリケーションのモニタリングサービスを設計し、システムのパフォーマンスを把握する方法をご紹介します。
レポート
このセッションは、「そもそもアプリケーションのパフォーマンスとは何か？」について確認し、「CloudWatchとX-Rayを利用したインサイトの収集、パフォーマンス制御の実装パターン」として具体的な監視方法を紹介する、という2つのパートで構成されていました。
What's APM
一言で言うと、「アプリのパフォーマンスを記録 / 監視 / 可視化し、パフォーマンスの問題に早期 / 自動的に対処する」ことである、とのことです。
パフォーマンスをレイヤーで考える
一口にパフォーマンスと言っても、いろんな見方があります。ここでは3つのレイヤーに分けて紹介されていました。
- インフラレイヤー
- リソースの利用率、IOPS、レイテンシーなど
- CloudWatchやZabbixで計測可能
- 局所的なメトリック
- アプリケーションレイヤー
- APIのレイテンシー、スループット、エラー率
- アプリケーションごとに計測 / 監視 / 可視化するべき指標が異なる
- （比較的）大局的なメトリック
- ビジネスレイヤー
- 業務の効率度合い、課金額、CVRなど
- 指標は千差万別（アプリよりも）
- KPIダッシュボード、経営分析、などと表現される
下位のレイヤーは上位のパフォーマンスに影響する、ということも重要なポイントです（インフラストラクチャーが最も下位のレイヤーで、ビジネスレイヤーが最も上位のレイヤーです）。
まとめると、
- レイヤーを分けて考えた方がいい
- レイヤーごとに管理の方法が違う
- 下位のレイヤーは上位のレイヤーに影響する
ここで畑さんは、「アプリケーションのレイヤーってケアできてないケース多くないですか？」と問題提起されていました。
・・・はい、おっしゃるとおりです。
パフォーマンスに影響を与える要因
大きく以下のように分類できます。
- ビジネス
- （経済的、社会的要因など）
- アプリケーション
- 負荷の増加（外的要因）
- 依存するサービスのトラブルや変更（外的要因）
- システムの変更（デプロイ）（内的要因）
- インフラストラクチャー
- Infrastructureのトラブル（外的要因）
- インフラストラクチャーの変更（内的要因）
外発的な要因は制御できないため、常に監視 / 対応できる必要があります。
内発的な要因は制御でき、デプロイやプロビジョニングはパフォーマンスと密接な関係があると言えます。
格言
"Everything fails all the time" by Werner Vogels
"All errors will be plus/minus three statement of the place where you last changed the program." by Joe Armstrong
管理とは？
- 管理する
- よく使われる言葉ですが、非常に曖昧
- 「管理」＝ 監視 + 可視化 + 対応
- 対応を忘れてはいけない
- すぐに実行できる、問題があればロールバックできる必要がある
実装例
AWSにおけるAPMの実装例が5つ紹介されていました。
アプリケーションのメトリクスを監視
- CloudWatchのカスタムメトリクスで実現可能
- アプリケーションからUDP Daemonにデータを送信
- CloudWatchにメトリクスを送信
- 認証情報はIAM Roleを利用
- オンプレミスでも同様のことが可能
- 認証情報はIAM Userのアクセスキーを利用
アプリケーションの重要処理をロギング
- 定量的な数値で残せない情報を記録
- メトリクスとしては表現できない詳細な情報
- CloudWatch Logsで実現可能
- ファイル出力
- CloudWatch Logs AgentでCloudWatch Logsにログを送信
- 認証情報はIAM Roleを利用
- オンプレミスでも同様のことが可能
- 認証情報はIAM Userのアクセスキーを利用
- ログの可視化も可能
- Logs > Metric Filter > Custom Metric
- Elasticsearch Serviceとの連携
- Lambdaと連携して、通知、詳細な解析、その他Lambdaでできることは何でもできる
シンセティックトラフィックを外形監視
- エンドユーザーの視点でパフォーマンスを監視
- LambdaによるHTTP(S)アクセスを行うことで実現可能
- 監視するLambdaをEventsで起動
- 結果をカスタムメトリックにPUT（到達性や遅延）
- 問題があればCloudWatch Alarmで通知
分散トレーシング
- マイクロサービスアーキテクチャーのサービスでは依存関係の可視化が必要
- X-Rayで対応できる
- X-Rayのメリット
- リクエスト実行状況の確認
- ボトルネックの特定
- アプリケーションの問題の検出
- 様々な言語への対応
- AWSとの連携 (EC2, ECS, Lambda, ElasticBeanstalk)
X-Rayについて
- 以下のような情報を表示可能
- レスポンスの正常性
- レイテンシの分布のグラフ
- トレースの概要を確認可能（フィルターを利用して異常なレスポンスやエラーのみを表示可能）
- 使い方
- アプリケーションにX-Rayのデーモンをインストール
- アプリケーションにSDKを組み込む
- オンプレミスでも利用可能
詳細は以下の資料が参考になります。
AWS Black Belt Online Seminar 2017 AWS X-Ray
デプロイメントパイプライン
APMと関係ないように思われるかも知れないが、デプロイを契機にパフォーマンスに影響を与える可能性があり、「管理（対応を含む）」を行うためには重要です。 新機能を追加することでパフォーマンスが低下した際にリソースの追加で対処することがあると思いますが、それはベストプラクティスではありません。
問題の無かった状態に戻すためにロールバックや、新機能を段階的に展開するためのカナリアリリースを行うには、デプロイメントパイプラインが整備されてないと現実的な運用は困難です。
CI/CDには以下のような分類があります。
- 継続的インテグレーション
- ビルドまでを自動化
- 継続的デリバリー
- デプロイ直前まで自動化
- デプロイは手動もしくは承認後に自動実行
- 継続的デプロイ
- デプロイまで全て自動化
CI/CDを実現するために、AWSでは以下のようなサービスを提供しています。
- ソース管理
- CodeCommit
- ビルド
- CodeBuild
- デプロイ、プロビジョニング
- CodeDeploy
- CloudFormation
- Elastic Beanstalk
- ワークフロー管理
- CodePipeline
CodeStarによって、上記のサービスを利用したCI/CD環境一式を作成することも可能です。
CodeDeploy
- In-Plac DeployやBlue/Green Deployに対応
- CodeDeploy Agentを利用したPull型のデプロイ
- ロールバックやデプロイ中に利用できるインスタンスの割合、トラフィックのルーティングの割合などを制御可能
まとめ
- レイヤーで分けて考えよう
- APMは「管理すること」
- 可視化までで安心してはいけない
- APMを行うためにCloudWatchやX-Rayなどのサービスが提供されている
まとめ（感想）
APMは言葉としては知っていましたし、実装例のいくつかは実際に利用したことがありますが、APMとは何かを実際に説明しろと言われるとここまできれいに説明することはできなかったと思います。 具体的な方法だけでなく、抽象的な考え方も理解していないと自分自身で納得もできないし他の人にその必要性を説明することも困難だと思います。 手法だけ知っていてもその効果や意味を知らないとかっこ悪いので、この領域に限らず物事をきちんと理解するよう努めたいなーと改めて思いました。
今年のAWS Summit Tokyoで聞いたセッションの中で個人的にはベストセッションでした。
現場からは以上です。
14
