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

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 • 開発初期段階では、サービスインさせるので手一杯になりがち。 • サービスの死活は、検知できるレベル。

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日間まで。 ※非同期の処理では、一部トレースが連続されない内容がある。

16. 4-2. Observability（可観測性） Copyright © Acroquest Technology Co., Ltd. All rights reserved. 16 Observabilityとは何か？ • 簡単にシステムの状態を把握したり、アプリケーションの動作を確認したりできること。 MonitoringとObservability • 「Observability」は「Monitoring」の上位互換のようなもの。 • 個人的には、障害の検知だけでなく、原因のトレースや、障害が発生する前にボトルネック等を取り除くための仕組み、と考えている。

19. 4-3. ロギング／メトリクス／トレーシング Copyright © Acroquest Technology Co., Ltd. All rights reserved. 19 ロギングメトリクストレーシング AWSにおける関連サービス Lambdaの関数ごとにログが分かれていて検索しにくかったりとそのまま利用はツライ Lambdaの関数や DynamoDBのテーブルが追加される度に、個別に追加する必要があり、そのまま利用はツライ AWS Lambdaを使う上ではかなり有用最初から適用をしておく CloudWatch Logs CloudWatch Metrics X-Ray

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 サービスの正常性確認異常／障害情報だけでなく、サービスが正常に稼働しているかどうかの確認も、可能なようにしている。 • バッチの実行結果 • バックアップの実行結果など • テキスト情報で分かりにくいものは、ヘッドレスブラウザを利用して、画面キャプチャを通知

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. ツールの導入ではなく、サービスの改善にフォーカス

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

Takanori Suzuki

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