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

1Copyright © Acroquest Technology Co., Ltd. All rights reserved.
サーバーレスなシステムのがんばらない運用監視
～ Monitoring から Observability へ～
2018/09/29
Acroquet Technology Co., Ltd.
鈴木貴典
Serverless Conf Tokyo 2018

プロフィール
Copyright © Acroquest Technology Co., Ltd. All rights reserved.
2
◼ 所属
• Acroquest Technology 株式会社
• 「働きがいのある会社」（GPTW）
3度目の1位受賞
◼ 主な業務内容
• テクニカルアーキテクト
• IoTサービス開発
• ビッグデータ／ストリームデータ関連開発
Twitter : @takanorig
Qiita : http://qiita.com/takanorig
鈴木貴典

はじめに
3
サーバーレスシステム開発バックグラウンド
① プラットフォームとしては、AWSを利用
（Lambda、DynamoDB、StepFunctions、Batchなど）
② 主に、ServerlessFrameworkを利用して開発
③ 自社のIoTデータ分析サービス「Torrentio（トレンティオ）」を
サーバーレスアーキテクチャで開発
④ その他IoTに限らず、複数のサービスを
サーバーレスアーキテクチャで開発
（車両管理、シェアリングサービス、ドローン活用システムなど）
本セッションの目的
サーバーレスなシステムの運用ってどうしているのか、
一緒に共有しましょう
• このセッションの内容が正解とは限らないが、実体験に基づくひとつの事例

本セッションにおける用語の定義
4
サーバーレス
アーキテクチャ
サーバーレス
システム
サーバーレスの考え方や、クラウドベンダーや
コンテナプラットフォームが提供するサービスを利用
したシステムの構成、および、設計手法。
サーバーレスアーキテクチャに基づき、構築された
システム自体。
サーバーレスサーバーを自前で立てずに、システムを構築すること。
FaaSの活用をメインとした開発・構築のこと。

目次
5
1. サーバーレスシステム
2. サーバーレスシステムの運用監視の課題
3. サーバーレスシステムの運用監視の発展（第一次）
4. サーバーレスシステムの運用監視の発展（第二次）
5. サーバーレスシステムの運用監視の発展（第三次）
6. 改善事例
7. 今後の取り組み

1. サーバーレスシステム（初期）
6
Amazon API
Gateway
AWS
Lambda
Amazon
DynamoDB
Amazon
Cognito
Amazon
S3
Amazon API
Gateway
AWS
Lambda
はじめは、このぐらいの感じ。
• バックエンドは、
API Gateway ＋ Lambdaで処理
• フロントエンドは、S3にコンテンツ
ファイルを置いてSPA化
• データはDynamoDBに保存
• Cognitoを使って、認証
サーバーレスの技術情報も、
最近は豊富に存在するので、
簡単に開発・構築できる。デバイス

1. サーバーレスシステム（実際）
7
実際にシステムを開発して、
運用するぐらいのレベルだと、
このぐらいになってくる。
• ファンクション数：約50～200個程度
• SNS, SQS, StepFunctions, Batch
なども利用して、イベントドリブンな
アーキテクチャに
ちゃんと、監視の対象や方法も
考えないと、運用で困ることに
なる。
デバイス

8
サーバーはなくても、ファンクションやサービスの
状況は監視する必要がある。
イベントドリブンなシステムは、どのように
呼び出されているか、どこで障害が発生しているか、
トレースが大変。
どれだけリソースを消費しているか、分かりにくく、
最適化が図りにくい（思わぬコスト増に）。

9
サーバーレスシステムでは、
開発容易性・開発スピードは向上するが、
運用監視は複雑化する。
メリットデメリット
従来型の
システム
• アプリケーションの構築は簡単。
• デバッグや運用も、比較的わかり
やすい。
• 冗長化などを、最初から考慮する
必要がある。
• サーバー自体の管理が必要になる。
サーバーレス
システム
• 開発のスピードはUPする。
• 拡張性／冗長化などをインフラ部
分（マネージドサービス）に任せ
て、アプリケーションの開発に集
中できる。
• デバッグが難しい。
• システムは細分化／分散化し、処
理の流れを把握するのが難しくな
る。

3. サーバーレスシステムの運用監視の発展（第一次）
10
第一次監視革命時代
• CloudWatchぐらいは
使っている。
• 基本、人力でデバッグ。
2016
• 開発初期段階では、サービスインさせるので手一杯になりがち。
• サービスの死活は、検知できるレベル。

3-1.【第一次監視革命時代】この頃の課題
11
問題発生時のデバッグ効率が悪い。
→原因特定、解決までに時間がかかる。
問題が発生してからでないと気づかない。
そもそも、監視できていない内容も多い。

4. サーバーレスシステムの運用監視の発展（第二次）
12
使っている。
第二次監視革命時代
• CloudWatchLogsの内容を見て、
自動でエラーチェック。
• X-Ray導入して、デバッグ効率や
性能改善が、大きく発展。
2016 2017

4-1. 分散トレーシング（X-Ray）
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
Lambdaだけでなく、DynamoDB, Kinesis,
SNS, SQSなどのマネージドサービスの呼び
出しの関連を俯瞰できる。
サービスマップ実行状況
処理時間のパーセンタイル
やエラーの発生状況を確認
できる。
トレース詳細
何の処理に、どれだけ時間が
かかっているかが分かる。
Lambdaの初期化にかかって
いる時間なども分かる。※データは、最大過去30日間まで。
※非同期の処理では、一部トレースが連続されない
内容がある。

15
常時このぐらいの処理が実行されている

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

4-3. ロギング／メトリクス／トレーシング
17
Amazon
CloudWatch
Amazon
CloudWatch
AWS
X-Ray

18
CloudWatch Logs CloudWatch Metrics X-Ray
ロギングメトリクストレーシング
AWSにおける関連サービス

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

4-4.【第一次監視革命時代】この頃の課題
20
監視自体のメンテナスに手間がかかる。
だんだんと、ダッシュボードなどを見なくなる。
→異常に気付かなくなる

21
Observability Is Not Just About
Logs, Metrics, and Traces
ログ、メトリック、トレースは、システムのテスト、理解、
デバッグを支援する便利なツールです。
ただし、ログ、メトリック、およびトレースを明示的に
使用しても、観察可能なシステムにはならないことに
注意することが重要です。
Cindy Sridharan

5. サーバーレスシステムの運用監視の発展（第三次）
22
使っている。
（サービスインさせるので手一杯）
• X-Ray導入して、デバッグ効率
や性能改善が、大きく発展。
第三次監視革命時代
• サービスの稼働状況などを、
いろいろと自動通知。
• 問題発生前に、サービス改善。
2016 2017 2018

5-1. ロギング／メトリクス／トレーシング＋α
23
• アラート（通知）
• 見せる化（可視化）
Datadogなどで対応できる部分も
多かったが、一部、実現できる
内容が不足する状況だったので、
現状は、AWSのAPI＋自作で実現
している。
＋
そう、これも
サーバーレスでね！

5-2. アラートと見せる化
24
ログのキーワード監視 1. CloudWatch Logsに出力されるログを、
一定時間ごとにチェック。
• メトリクスフィルタやサブスクリプションでは、
やりたいことが実現できなかった。
• Lambdaのログは、関数ごとにグループが分か
れるが、横断でチェックが可能なようにしている。
2. 特定のキーワード（“error”や“exception”など）
を正規表現でチェックし、その内容を検出した
際に、該当部分のログをSlackに通知。
3. Slackには、CloudWatch Logsへのリンクを
設定し、それをクリックしたら、ダイレクトに
ログの内容を確認できるようにしている。
• すぐに、問題発生個所の前後も含めて、状況を
確認できる。

25
Lambda 関数の実行時間
指定している実行時間制限の80％を超過
したら、アラート。
DynamoDB
Read／Writeの
キャパシティの消費量
指定しているキャパシティの80％を超過
したら、アラート。
リソースの監視
主に以下の内容を監視しており、リソース不足や不適切な設定の影響で、
サービスに支障が発生する前に、対応できるようにしている。
該当するテーブルの
メトリクス状況に、
リンクで飛べるように
している。

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

参考）Datadogの利用
27
関数が増えても、
自動で追加
時間は、絶対時間
Lambda

参考）Datadogの利用
28
DynamoDB
テーブルが増えても、
自動で追加
キャパシティは、絶対値で
はなく、割合で計算される

5-3. Observabilityに基づく取り組み
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
どのようなツールを導入するにしても、
対象となるサーバーレスシステムに対して、
継続的に活用・拡張していくことが重要
（ツールの導入ではなく、サービスの改善にフォーカス）

6. 改善事例① ~想定外に時間がかかる処理の早期検出~
30
DailyBatchが正常終了しました
（ExecutionTime：243.2 秒）
• バッチ処理はLambdaで動作。
• 安全のために、最大5分実行できる
ようにしていたが（Lambdaの上
限値）、それを超えそうな状況。 • StepFuncsionsから呼び出されている
Lambdaで、時間がかかっている。

6. 改善事例① ~想定外に時間がかかる処理の早期検出~
31
• プログラム内で、DynamoDBのTTL（Time To Live）の設定値を取得しており、
そこで、1テーブルあたり約3秒の時間がかかっていた。
• 全テーブル分の取得処理をしていたため、大きく処理時間がかかっていた。
→ 処理方法を変えて、サービスで問題となる前に改善！
StepFunctionsの実行詳細 X-Rayのトレース詳細

6. 改善事例② ~キャパシティの最適化~
32
AWS
Lambda
Amazon
DynamoDB
AWS
Lambda
AWS
Lambda
Lambda実行時に、DynamoDBから、
複数件のデータを取得する必要あり。
• Redis等を使うほどではない。
• ただ、DynamoDBのキャパシティの設定は
心配。
バーストすることもあり、
どの程度のキャパシティを設定するか、
想定がつきにくい。
→DynamoDBでキャパシティを超過すると、
データが取得できなくなり、サービス時の
影響が大きい。
Scan
※前提として、サーバーレスで、DynamoDBの
Scanは、できるだけ使わない方が良いですよ。
本当に使う必要があるのかを、よく考えましょう。

33
正常時
10ms程度で完了している。
異常時
159msと、正常時の約15倍
の時間がかかっている。
アクセスが増えると、
より処理時間が長くなり、
サービス障害に発展する。
→ この状況を踏まえて、キャパシティ設定を変更。
トレーシングにより、通常運用では気づきにくい、
ミリ秒レベルの処理も見逃さずにチューニング

34
Lambda
X-Rayのトレーシングの内容を見ていたら、こんな問題にも気づいた
Lambdaの初期化に時間がかかっている。
同時実行数が多すぎて、待ちが発生している。
→ 関数の同時実行数を制限して、必要以上にリソースを
消費しないように調整。

7. 今後の取り組み
35
使っている。
（サービスインさせるので手一杯）
• X-Ray導入して、デバッグ効率
や性能改善が、大きく発展。
第三次監視革命時代
• サービスの稼働状況などを、
いろいろと自動通知。
• 問題発生前に、サービス改善。
2016 2017 2018
第四次監視革命時代
• コンテナ連携
→ECS、SageMakerなど
• マルチクラウド対応
今後

まとめ
36
1. サーバーレスアーキテクチャで、開発効率や開発のスピードが
向上し、早くサービスを立ち上げ／拡張できるようになった。
2. ただし、サーバーレスシステムでは、運用監視は複雑化する。
3. Observability＝ロギング／メトリクス／トレーシング
＋α（アラートや見せる化など）
4. Serverless向けのモニタリングツールや、Observability関連の
ツールも充実してきている。
5. ツールの導入ではなく、サービスの改善にフォーカス

一緒に働く仲間を募集しています！
37
Our Vision
テクノロジストチームとして、
ビジネスの革新的価値創出に挑戦する

38
ご清聴ありがとうございました。
Infrastructures Evolution

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

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

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

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

Más de Takanori Suzuki

Más de Takanori Suzuki (10)

Último

Último (8)

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