KinesisとLambdaでつくる Serverlessなログ基盤

Torgayev Tamirlan

Cloud Technologies Advisor @ CyberAgent, Inc.

• 2018年 サイバーエージェント新卒入社

• Cloud Technologies Advisor = (SA+SRE+DevOps+Infra) / 4

• AWSメインで様々なサービスをサポート

• AWA: DB復旧高速化 (12h→55m)、ECS EC2 スケールイン保

護

• Torte立ち上げ

• AWA、タップル誕生、CROSSME、REQUを含む

13サービス担当

• 好きなAWSのサービス: ECS

自己紹介

Torgayev Tamirlan @prog893

今日話すこと

• Kinesis、Kinesis+Lambdaの選定理由

• これらを利用しているいくつかの弊社サービスのロギングアーキテクチャを紹介

• 最後にちょっとしたサプライズあり

今日話さないこと

• fluentdの細かい話

• Kinesis/Lambda/S3/ES/… is 何

• 紹介するサービスのバックエンドの詳細 (言語、構成、etc.)

• Internal BIやContents moderation基盤の詳細

Disclaimer

• fluentdを捨てる話をしますが、fluentdが嫌いというわけではない

• むしろ好き

• fluentdの検証、構築が弊社での最初の仕事で、

それがなければ正式入社できていないかもしれない

• fluentdやflumeのようなミドルウェアが適切である事例もたくさんある

• 担当サービスの要望駆動で動くロールとして働いているので悪しからず

How we did it before従来のログ転送パターンや課題

• 各サーバ/コンテナでfluentdをDaemon/Sidecarとして乗せてログ転送

• そのDaemon/sidecarが最終的な格納先 (以後sink) に直接格納

EC2 アプリ + fluentd

daemon

S3 Bucket ログの保存

Internal BI fluentd endpoint

Contents Moderation fluentd endpoint

従来のログ転送: 直接格納パターン

従来のログ転送: 集約パターン• 各サーバ/コンテナでfluentdをDaemon/Sidecarとして乗せてログ転送

• fluentd Aggregator (Active/Active冗長化) でログを集約し、sinkに転送

ECS Service アプリ+fluentdコンテナ相乗り

EC2 fluentd aggregator

S3 Bucket ログの保存

Internal BI Kinesis ingest

Contents Moderation Kinesis ingest

アプリケーションが死んでも、ログが集約サーバまで届いていればOK

sinkが溜まっていても 集約サーバはずっといるのでリトライできる

☝

👈

従来の課題点• メンテナンスコスト

• スケールアウト・スケールインの手間、拡張コスト

• 集約サーバ増減やsink追加でDaemon/Sidecarのコンフィグ修正、

デプロイが発生

• 欠損リスク

• バッファ送りきってないサーバのスケールインなどによるサービスアウト

• 設定を間違えると、バッファ溢れなどで欠損、事故発生

Logging Challengesログ基盤の構成に対する要件と課題

Logging Challenges

1. 信頼性

2. メンテナンスコスト

3. スケーラビリティ

4. 拡張性

5. 汎用性

Challenge: 信頼性• マッチングサービスのようなログ要件が厳しいサービスでは、 ほとんどのログに対する要件が完全に欠損なし

• Contents moderation用のログやアクセスログを含む

• ALBのアクセスログだけではダメだったり

• 欠損した際のリトライ機構、壊れたログが流れたときの救出フローが必要

• fluentdのコンフィグでもできるが、コンフィグがRubyだらけになり、

メンテナンスコスト増加

Challenge: メンテナンスコスト

• Sidecar/Daemon fluentd (などのミドルウェア) を利用すると、

それらの管理、メンテナンスが必要

• さらに、集約パターンでは集約サーバの面倒を見ないといけない

• そこがダメになると全部ダメ

• ディスク、死活監視、fluentdバッファ状態、セキュリティパッチや

OS更新など

Challenge: スケーラビリティ• 簡単にスケーリングできるようにしたい

• 簡単 = サーバ構築、Ansible流しより簡単

• ログの出力が著しく増えることが想定されないので、オートスケーリングは必須ではない

• ディスク容量やバッファサイズよりスループットベースで パフォーマンスを指定したい

• こちらの方がDevOpsやSREじゃない開発者にとって一番わかりやすい

Challenge: 拡張性

• 格納先が増えれば、安易に行えるようにしたい

• 例: Kibanaを使ったログ可視化を導入したい

• 安易 = アプリケーション等のデプロイなし

Challenge: 汎用性

• どのようなサービスや要件にも対応できる構成

• ニーズに合わせて微調整できる構成

After *a lot* of sleepless nights. . .

数えきれない眠れぬ夜を経て…

Serverless Logging withKinesis and Lambda

KinesisとLambdaを活用したログ基盤の構成

なぜ Kinesis

• Bufferや「容量」という概念がない

• 保持期間、スループットだけ気にすれば良い

• 直感的なパフォーマンス設定

• 1シャードあたりのスループットが決まっていて、

スループットを増やしたければシャードを増やすだけ

• reshardが自動で行われる

なぜ Kinesis + Lambda• Kinesis + Lambda Event Source Mappingでは、リトライが自動

• Lambdaが失敗すれば、同じデータで再実行

• そのデータが失効 OR Lambdaの実行が成功で終了するまでリトライ

(どちらか早い方)

• Kinesis上のデータをどこまで処理したかのポジション管理もされる

• 自前で用意するものはデータの処理や転送用の仕組みだけ! 楽チン!

構成 v1

• Kinesis Streams -> Lambda -> 各種 sink (S3/ES/Internal BI etc.)

• Kinesisへの格納はサービスの要件／状態による

• 相乗りfluentd + aws-fluent-plugin-kinesis

• Kinesis APIでアプリケーションのコードから直接格納

事例1：タップル誕生

ECS Service アプリ+fluentdコンテナ相乗り

EC2 fluentd aggregator

KDS to Elasticsearch

S3 Bucket ログの保存

Lambda lambda-kinesis-to-es

Elasticsearch Service ログ調査 with Kibana

fluentd + aws-fluent-plugin-kinesis

KDS to BI

Internal BI Kinesis ingest

KDS to Contents Moderation

Contents Moderation Kinesis ingest

fluentd + aws-fluent-plugin-kinesis

fluentd + aws-fluent-plugin-kinesis

事例2：CROSSME

EC2 アプリ

KDS to BI

Kinesis SDK転送

Internal BI Kinesis ingest

KDS to Contents Moderation

Contents Moderation Kinesis ingest

KDS to Elasticsearch

Lambda lambda-kinesis-to-es

Elasticsearch Service ログ調査 with Kibana

Kinesis SDK転送

Kinesis SDK転送 Lambda lambda-kinesis-to-es

S3 Bucket ログの保存

事例3：REQU

S3 Bucket ログの保存

KDS to Elasticsearch

Lambda lambda-kinesis-to-es

Elasticsearch Service ログ調査 with Kibana

KDS to Contents Moderation

Lambda lambda-kinesis-to-s3

ECS Service アプリ

Kinesis SDK転送

Kinesis SDK転送

Contents Moderation Kinesis ingest

Logging Challenges 答え合わせ

1. 信頼性: Kinesisでの集約、Kinesis+Lambdaのリトライ機構

2. メンテナンスコスト: Serverless、Full-Managed

3. スケーラビリティ: Kinesisシャード追加、自動リシャード

4. 拡張性: Lambdaモジュールを好きに組み合わせできる

5. 汎用性: どのサービスの要望にも対応できるLambdaモジュールの開発

Feedback

• 「集約用fluentdが捨てられて気持ちいい、残ったものも捨てたい」

• 「fluent-plugin-kinesisに頼りたくない」

• 「fluent-plugin-kinesisのバッファ設定などconfの管理がめんどい」

• 「Kinesis APIを叩くパターンで、fluentd相当の実装をしたくない」

Serverless Logging withKinesis and Lambdaさらに進化したKinesisとLambdaを活用したログ基盤の構成

*Better

Serverlessなログ基盤の構成

• 完全にfluentdなどのミドルウェアさようならパターン

• ECS -> stdout -> CWL -> CWL Subscription Filters -> Kinesis “router” -> Lambda forwarder -> Kinesis sinks/S3/ES

• Internal BIツールやContents moderation基盤は、それぞれの開発チームと

連携し、各AWSアカウントのKinesisストリームから読み込むように変更

• EC2もCloudWatch Agent利用で使える

事例4：開発中新規サービスx2

S3 Bucket ログの保存

Lambda lambda-kinesis-to-es

Elasticsearch Service ログ調査用ES+Kibana

Lambda lambda-kinesis-to-s3

KDS router

Internal BI Kinesis ingest

CloudWatch Logs

Lambda lambda-kinesis-forward

KDS to BI

KDS to Contents Moderation

Contents Moderation Kinesis ingest

※ lambda-kinesis-forwardがクリティカルパスになり、 全てのイベントを取得する必要があるのでEFO利用がオススメ

ECS Service アプリ

CloudWatch Logs Subscription Filters

注意: CloudWatch LogsのPutLogEventsは高い

(Kinesisも...安くはない)

💴 札束 💴 で信頼性を買っているようなもの

ただ、例えばECSのロギングドライバでKinesisへの格納ができるように

なったとしても、Kinesisのキャパやログ周りLambdaの不具合などから

ログを守るためのバックアップが欲しい

About Baikonur OSSBaikonur OSSプロジェクトについて

Baikonur OSS Project

• Terraform Moduleや各種ツールの共通化プロジェクト

• GitHub.com、Terraform Module Registry

• 弊社で開発、利用しているモジュールを順次OSS化

• 弊社内: AWSモジュール23種類

• 名前の由来：バイコヌール宇宙基地

• そのまま使える、すぐ展開できるベストプラクティス

Baikonur OSS modules

• 本日紹介した全てのLambdaはBaikonurで紹介されています

• 楽に構築ができるTerraform Moduleも提供

• 弊社内で使っているものをそのまま公開

番外: eden

• ECS Dynamic Environment Manager = eden

• ECSの開発環境を動的に作成するツールもBaikonur OSSで公開

• 詳細: http://bit.ly/awseden

Kinesis CaveatsKinesisを利用するにあたって注意すべきところ

Scaling• シャード数変更でできないこと (ドキュメンテーション) :

• 24時間で3回以上のシャード数変更

• 現在のシャード数より2倍より多い、半分より少ないシャード数への変更

• 500シャードより多いシャード数への変更

• 500シャードより多いシャードを持つストリームのスケールダウン不可 👈 🤔

• アカウント単位のシャード数の上限の突破

• 全部上限緩和可能

Autoscaling• オートスケーリングは提供されていない

• awslabs/amazon-kinesis-scaling-utils を使えばオートスケーリングっぽい

ことができる

• 私の経験ではオートスケーリングが必要になったことはない

• 書き込み、読み込み失敗数の監視を追加し、 異常検知をトリガーに手動でシャード増加できれば十分

• Capacity Exceededでリトライするロジック各所で実装済み

• 上記scaling-utilsをPythonで書き直して将来的にオートスケールするかも

Read Capacity: transactions問題• Kinesis+Lambdaでは、1シャードあたり同じLambdaが

同時に1回のみ実行される

• 読み込みスループットには、5 transactions/secという制限がある

• 1 Lambda連携1シャードあたり～1 transaction/secが消費される

• 処理できる新しいデータがないかの確認を毎秒実行

• 3 Lambda以上利用したい場合、3つ目以降は EFO Pipes で専用スループット確保

• Enhanced Fan-out

Conclusion総括

総括

• Kinesis + Lambdaで気軽に拡張可能なロギングアーキテクチャを実現

• Lambda連携で自動リトライ、実装では格納とエラー処理のみで十分

• KinesisとLambdaの活用でServerless構成、メンテナンスコスト減

• 共通化、OSS化によって導入コスト減

Thank you for listening!ご静聴ありがとうございました