ServerlessConf Tokyo2018 サーバーレスなシステムのがんばらない運用監視 / ServerlessConfTokyo2018_ServerlessObservability

ServerlessConf 2018Tokyo での登壇資料です。
サーバーレスなシステムのがんばらない運用監視
～Monitoring から Observability へ～

Transcript

1. 1 Copyright © Acroquest Technology Co., Ltd. All rights reserved. サーバーレスなシステムのがんばらない運用監視 ～ Monitoring から Observability へ ～ 2018/09/29 Acroquet Technology Co., Ltd. 鈴木 貴典 Serverless Conf Tokyo 2018
2. プロフィール Copyright © Acroquest Technology Co., Ltd. All rights reserved. 2 ◼ 所属 • Acroquest Technology 株式会社 • 「働きがいのある会社」（GPTW） 3度目の1位 受賞 ◼ 主な業務内容 • テクニカルアーキテクト • IoTサービス開発 • ビッグデータ／ストリームデータ関連開発 Twitter : @takanorig Qiita : http://qiita.com/takanorig 鈴木 貴典
3. はじめに Copyright © Acroquest Technology Co., Ltd. All rights reserved. 3 サーバーレスシステム開発バックグラウンド ① プラットフォームとしては、AWSを利用 （Lambda、DynamoDB、StepFunctions、Batchなど） ② 主に、ServerlessFrameworkを利用して開発 ③ 自社のIoTデータ分析サービス「Torrentio（トレンティオ）」を サーバーレスアーキテクチャで開発 ④ その他IoTに限らず、複数のサービスを サーバーレスアーキテクチャで開発 （車両管理、シェアリングサービス、ドローン活用システムなど） 本セッションの目的 サーバーレスなシステムの運用ってどうしているのか、 一緒に共有しましょう • このセッションの内容が正解とは限らないが、実体験に基づくひとつの事例
4. 本セッションにおける用語の定義 Copyright © Acroquest Technology Co., Ltd. All rights reserved. 4 サーバーレス アーキテクチャ サーバーレス システム サーバーレスの考え方や、クラウドベンダーや コンテナプラットフォームが提供するサービスを利用 したシステムの構成、および、設計手法。 サーバーレスアーキテクチャに基づき、構築された システム自体。 サーバーレス サーバーを自前で立てずに、システムを構築すること。 FaaSの活用をメインとした開発・構築のこと。
5. 目次 Copyright © Acroquest Technology Co., Ltd. All rights reserved. 5 1. サーバーレスシステム 2. サーバーレスシステムの運用監視の課題 3. サーバーレスシステムの運用監視の発展（第一次） 4. サーバーレスシステムの運用監視の発展（第二次） 5. サーバーレスシステムの運用監視の発展（第三次） 6. 改善事例 7. 今後の取り組み
6. 1. サーバーレスシステム（初期） Copyright © Acroquest Technology Co., Ltd. All rights reserved. 6 Amazon API Gateway AWS Lambda Amazon DynamoDB Amazon Cognito Amazon S3 Amazon API Gateway AWS Lambda はじめは、このぐらいの感じ。 • バックエンドは、 API Gateway ＋ Lambdaで処理 • フロントエンドは、S3にコンテンツ ファイルを置いてSPA化 • データはDynamoDBに保存 • Cognitoを使って、認証 サーバーレスの技術情報も、 最近は豊富に存在するので、 簡単に開発・構築できる。 デバイス
7. 1. サーバーレスシステム（実際） Copyright © Acroquest Technology Co., Ltd. All rights reserved. 7 実際にシステムを開発して、 運用するぐらいのレベルだと、 このぐらいになってくる。 • ファンクション数：約50～200個程度 • SNS, SQS, StepFunctions, Batch なども利用して、イベントドリブンな アーキテクチャに ちゃんと、監視の対象や方法も 考えないと、運用で困ることに なる。 デバイス
8. 2. サーバーレスシステムの運用監視の課題 Copyright © Acroquest Technology Co., Ltd. All rights reserved. 8 サーバーはなくても、ファンクションやサービスの 状況は監視する必要がある。 イベントドリブンなシステムは、どのように 呼び出されているか、どこで障害が発生しているか、 トレースが大変。 どれだけリソースを消費しているか、分かりにくく、 最適化が図りにくい（思わぬコスト増に）。
9. 2. サーバーレスシステムの運用監視の課題 Copyright © Acroquest Technology Co., Ltd. All rights reserved. 9 サーバーレスシステムでは、 開発容易性・開発スピードは向上するが、 運用監視は複雑化する。 メリット デメリット 従来型の システム • アプリケーションの構築は簡単。 • デバッグや運用も、比較的わかり やすい。 • 冗長化などを、最初から考慮する 必要がある。 • サーバー自体の管理が必要になる。 サーバーレス システム • 開発のスピードはUPする。 • 拡張性／冗長化などをインフラ部 分（マネージドサービス）に任せ て、アプリケーションの開発に集 中できる。 • デバッグが難しい。 • システムは細分化／分散化し、処 理の流れを把握するのが難しくな る。
10. 3. サーバーレスシステムの運用監視の発展（第一次） Copyright © Acroquest Technology Co., Ltd. All rights reserved. 10 第一次監視革命時代 • CloudWatchぐらいは 使っている。 • 基本、人力でデバッグ。 2016 • 開発初期段階では、サービスインさせるので手一杯になりがち。 • サービスの死活は、検知できるレベル。
11. 3-1.【第一次監視革命時代】この頃の課題 Copyright © Acroquest Technology Co., Ltd. All rights reserved. 11 問題発生時のデバッグ効率が悪い。 →原因特定、解決までに時間がかかる。 問題が発生してからでないと気づかない。 そもそも、監視できていない内容も多い。
12. 4. サーバーレスシステムの運用監視の発展（第二次） Copyright © Acroquest Technology Co., Ltd. All rights reserved. 12 第一次監視革命時代 • CloudWatchぐらいは 使っている。 • 基本、人力でデバッグ。 第二次監視革命時代 • CloudWatchLogsの内容を見て、 自動でエラーチェック。 • X-Ray導入して、デバッグ効率や 性能改善が、大きく発展。 2016 2017
13. 4-1. 分散トレーシング（X-Ray） Copyright © Acroquest Technology Co., Ltd. All rights reserved. 13 # AWS X-Rayのライブラリを読み込み from aws_xray_sdk.core import xray_recorder from aws_xray_sdk.core import patch_all # AWS X-Rayのパッチを適用 patch_all() plugins: - serverless-plugin-tracing provider: name: aws runtime: python3.6 tracing: true iamRoleStatements: - Effect: Allow Action: - xray:PutTraceSegments - xray:PutTelemetryRecords Resource: "*" Severless.yml(SeverlessFramework) Lambda(Python) たった、これだけの内容で、分散トレーシングを実現！
14. 4-1. 分散トレーシング（X-Ray） Copyright © Acroquest Technology Co., Ltd. All rights reserved. 14 Lambdaだけでなく、DynamoDB, Kinesis, SNS, SQSなどのマネージドサービスの呼び 出しの関連を俯瞰できる。 サービスマップ 実行状況 処理時間のパーセンタイル やエラーの発生状況を確認 できる。 トレース詳細 何の処理に、どれだけ時間が かかっているかが分かる。 Lambdaの初期化にかかって いる時間なども分かる。 ※データは、最大過去30日間まで。 ※非同期の処理では、一部トレースが連続されない 内容がある。
15. 4-1. 分散トレーシング（X-Ray） Copyright © Acroquest Technology Co., Ltd. All rights reserved. 15 常時このぐらいの処理が実行されている
16. 4-2. Observability（可観測性） Copyright © Acroquest Technology Co., Ltd. All rights reserved. 16 Observabilityとは何か？ • 簡単にシステムの状態を把握したり、アプリケーションの動作を 確認したりできること。 MonitoringとObservability • 「Observability」 は「Monitoring」の上位互換のようなもの。 • 個人的には、障害の検知だけでなく、原因のトレースや、障害が 発生する前にボトルネック等を取り除くための仕組み、と考えている。
17. 4-3. ロギング／メトリクス／トレーシング Copyright © Acroquest Technology Co., Ltd. All rights reserved. 17 Amazon CloudWatch Amazon CloudWatch AWS X-Ray
18. 4-3. ロギング／メトリクス／トレーシング Copyright © Acroquest Technology Co., Ltd. All rights reserved. 18 CloudWatch Logs CloudWatch Metrics X-Ray ロギング メトリクス トレーシング AWSにおける関連サービス
19. 4-3. ロギング／メトリクス／トレーシング Copyright © Acroquest Technology Co., Ltd. All rights reserved. 19 ロギング メトリクス トレーシング AWSにおける関連サービス Lambdaの関数ごとに ログが分かれていて 検索しにくかったりと そのまま利用はツライ Lambdaの関数や DynamoDBのテーブルが 追加される度に、 個別に追加する必要があり、 そのまま利用はツライ AWS Lambdaを使う上では かなり有用 最初から適用をしておく CloudWatch Logs CloudWatch Metrics X-Ray
20. 4-4.【第一次監視革命時代】この頃の課題 Copyright © Acroquest Technology Co., Ltd. All rights reserved. 20 監視自体のメンテナスに手間がかかる。 だんだんと、ダッシュボードなどを見なくなる。 →異常に気付かなくなる
21. Copyright © Acroquest Technology Co., Ltd. All rights reserved. 21 Observability Is Not Just About Logs, Metrics, and Traces ログ、メトリック、トレースは、システムのテスト、理解、 デバッグを支援する便利なツールです。 ただし、ログ、メトリック、およびトレースを明示的に 使用しても、観察可能なシステムにはならないことに 注意することが重要です。 Cindy Sridharan
22. 5. サーバーレスシステムの運用監視の発展（第三次） Copyright © Acroquest Technology Co., Ltd. All rights reserved. 22 第一次監視革命時代 • CloudWatchぐらいは 使っている。 • 基本、人力でデバッグ。 （サービスインさせるので手一杯） 第二次監視革命時代 • CloudWatchLogsの内容を見て、 自動でエラーチェック。 • X-Ray導入して、デバッグ効率 や性能改善が、大きく発展。 第三次監視革命時代 • サービスの稼働状況などを、 いろいろと自動通知。 • 問題発生前に、サービス改善。 2016 2017 2018
23. 5-1. ロギング／メトリクス／トレーシング＋α Copyright © Acroquest Technology Co., Ltd. All rights reserved. 23 • アラート（通知） • 見せる化（可視化） Datadogなどで対応できる部分も 多かったが、一部、実現できる 内容が不足する状況だったので、 現状は、AWSのAPI＋自作で実現 している。 ＋ そう、これも サーバーレスでね！
24. 5-2. アラートと見せる化 Copyright © Acroquest Technology Co., Ltd. All rights reserved. 24 ログのキーワード監視 1. CloudWatch Logsに出力されるログを、 一定時間ごとにチェック。 • メトリクスフィルタやサブスクリプションでは、 やりたいことが実現できなかった。 • Lambdaのログは、関数ごとにグループが分か れるが、横断でチェックが可能なようにしている。 2. 特定のキーワード（“error”や“exception”など） を正規表現でチェックし、その内容を検出した 際に、該当部分のログをSlackに通知。 3. Slackには、CloudWatch Logsへのリンクを 設定し、それをクリックしたら、ダイレクトに ログの内容を確認できるようにしている。 • すぐに、問題発生個所の前後も含めて、状況を 確認できる。
25. 5-2. アラートと見せる化 Copyright © Acroquest Technology Co., Ltd. All rights reserved. 25 Lambda 関数の実行時間 指定している実行時間制限の80％を超過 したら、アラート。 DynamoDB Read／Writeの キャパシティの消費量 指定しているキャパシティの80％を超過 したら、アラート。 リソースの監視 主に以下の内容を監視しており、リソース不足や不適切な設定の影響で、 サービスに支障が発生する前に、対応できるようにしている。 該当するテーブルの メトリクス状況に、 リンクで飛べるように している。
26. 5-2. アラートと見せる化 Copyright © Acroquest Technology Co., Ltd. All rights reserved. 26 サービスの正常性確認 異常／障害情報だけでなく、サービスが正常に稼働しているかどうかの 確認も、可能なようにしている。 • バッチの実行結果 • バックアップの実行結果 など • テキスト情報で分かりにくいものは、 ヘッドレスブラウザを利用して、 画面キャプチャを通知
27. 参考）Datadogの利用 Copyright © Acroquest Technology Co., Ltd. All rights reserved. 27 関数が増えても、 自動で追加 時間は、絶対時間 Lambda
28. 参考）Datadogの利用 Copyright © Acroquest Technology Co., Ltd. All rights reserved. 28 DynamoDB テーブルが増えても、 自動で追加 キャパシティは、絶対値で はなく、割合で計算される
29. 5-3. Observabilityに基づく取り組み Copyright © Acroquest Technology Co., Ltd. All rights reserved. 29 ログ、メトリック、トレースの サービス自体は、各クラウド ベンダーが提供してきている。 AWS Azure GCP FaaS Lambda Functions Cloud Functions ロギング CloudWatch Logs Azure Monitor Stackdriver Logging メトリクス CloudWatch Metrics Azure Monitor Stackdriver Monitoring 分散 トレース X-Ray Application Insights Stackdriver Trace サーバーレス向けのモニタリング サービスも増えてきている。 Thundra IOpipe Epsagon どのようなツールを導入するにしても、 対象となるサーバーレスシステムに対して、 継続的に活用・拡張していくことが重要 （ツールの導入ではなく、サービスの改善にフォーカス）
30. 6. 改善事例① ~想定外に時間がかかる処理の早期検出~ Copyright © Acroquest Technology Co., Ltd. All rights reserved. 30 DailyBatchが正常終了しました （ExecutionTime：243.2 秒） • バッチ処理はLambdaで動作。 • 安全のために、最大5分実行できる ようにしていたが（Lambdaの上 限値）、それを超えそうな状況。 • StepFuncsionsから呼び出されている Lambdaで、時間がかかっている。
31. 6. 改善事例① ~想定外に時間がかかる処理の早期検出~ Copyright © Acroquest Technology Co., Ltd. All rights reserved. 31 • プログラム内で、DynamoDBのTTL（Time To Live）の設定値を取得しており、 そこで、1テーブルあたり約3秒の時間がかかっていた。 • 全テーブル分の取得処理をしていたため、大きく処理時間がかかっていた。 → 処理方法を変えて、サービスで問題となる前に改善！ StepFunctionsの実行詳細 X-Rayのトレース詳細
32. 6. 改善事例② ~キャパシティの最適化~ Copyright © Acroquest Technology Co., Ltd. All rights reserved. 32 AWS Lambda Amazon DynamoDB AWS Lambda AWS Lambda Lambda実行時に、DynamoDBから、 複数件のデータを取得する必要あり。 • Redis等を使うほどではない。 • ただ、DynamoDBのキャパシティの設定は 心配。 バーストすることもあり、 どの程度のキャパシティを設定するか、 想定がつきにくい。 →DynamoDBでキャパシティを超過すると、 データが取得できなくなり、サービス時の 影響が大きい。 Scan ※前提として、サーバーレスで、DynamoDBの Scanは、できるだけ使わない方が良いですよ。 本当に使う必要があるのかを、よく考えましょう。
33. 6. 改善事例② ~キャパシティの最適化~ Copyright © Acroquest Technology Co., Ltd. All rights reserved. 33 正常時 10ms程度で完了している。 異常時 159msと、正常時の約15倍 の時間がかかっている。 アクセスが増えると、 より処理時間が長くなり、 サービス障害に発展する。 → この状況を踏まえて、キャパシティ設定を変更。 トレーシングにより、通常運用では気づきにくい、 ミリ秒レベルの処理も見逃さずにチューニング
34. 6. 改善事例② ~キャパシティの最適化~ Copyright © Acroquest Technology Co., Ltd. All rights reserved. 34 Lambda X-Rayのトレーシングの内容を見ていたら、こんな問題にも気づいた Lambdaの初期化に時間がかかっている。 同時実行数が多すぎて、待ちが発生している。 → 関数の同時実行数を制限して、必要以上にリソースを 消費しないように調整。
35. 7. 今後の取り組み Copyright © Acroquest Technology Co., Ltd. All rights reserved. 35 第一次監視革命時代 • CloudWatchぐらいは 使っている。 • 基本、人力でデバッグ。 （サービスインさせるので手一杯） 第二次監視革命時代 • CloudWatchLogsの内容を見て、 自動でエラーチェック。 • X-Ray導入して、デバッグ効率 や性能改善が、大きく発展。 第三次監視革命時代 • サービスの稼働状況などを、 いろいろと自動通知。 • 問題発生前に、サービス改善。 2016 2017 2018 第四次監視革命時代 • コンテナ連携 →ECS、SageMakerなど • マルチクラウド対応 今後
36. まとめ Copyright © Acroquest Technology Co., Ltd. All rights reserved. 36 1. サーバーレスアーキテクチャで、開発効率や開発のスピードが 向上し、早くサービスを立ち上げ／拡張できるようになった。 2. ただし、サーバーレスシステムでは、運用監視は複雑化する。 3. Observability＝ロギング／メトリクス／トレーシング ＋α（アラートや見せる化など） 4. Serverless向けのモニタリングツールや、Observability関連の ツールも充実してきている。 5. ツールの導入ではなく、サービスの改善にフォーカス
37. 一緒に働く仲間を募集しています！ Copyright © Acroquest Technology Co., Ltd. All rights reserved. 37 Our Vision テクノロジストチームとして、 ビジネスの革新的価値創出に挑戦する
38. Copyright © Acroquest Technology Co., Ltd. All rights reserved. 38 ご清聴ありがとうございました。 Infrastructures Evolution