devday 2019 - kinesisとlambdaでつくる serverlessなログ基盤 · baikonur oss project •...
Post on 09-Jul-2020
2 Views
Preview:
TRANSCRIPT
• 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
今日話さないこと
• fluentdの細かい話
• Kinesis/Lambda/S3/ES/… is 何
• 紹介するサービスのバックエンドの詳細 (言語、構成、etc.)
• Internal BIやContents moderation基盤の詳細
Disclaimer
• fluentdを捨てる話をしますが、fluentdが嫌いというわけではない
• むしろ好き
• fluentdの検証、構築が弊社での最初の仕事で、
それがなければ正式入社できていないかもしれない
• fluentdやflumeのようなミドルウェアが適切である事例もたくさんある
• 担当サービスの要望駆動で動くロールとして働いているので悪しからず
• 各サーバ/コンテナで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のコンフィグ修正、
デプロイが発生
• 欠損リスク
• バッファ送りきってないサーバのスケールインなどによるサービスアウト
• 設定を間違えると、バッファ溢れなどで欠損、事故発生
Challenge: 信頼性• マッチングサービスのようなログ要件が厳しいサービスでは、 ほとんどのログに対する要件が完全に欠損なし
• Contents moderation用のログやアクセスログを含む
• ALBのアクセスログだけではダメだったり
• 欠損した際のリトライ機構、壊れたログが流れたときの救出フローが必要
• fluentdのコンフィグでもできるが、コンフィグがRubyだらけになり、
メンテナンスコスト増加
Challenge: メンテナンスコスト
• Sidecar/Daemon fluentd (などのミドルウェア) を利用すると、
それらの管理、メンテナンスが必要
• さらに、集約パターンでは集約サーバの面倒を見ないといけない
• そこがダメになると全部ダメ
• ディスク、死活監視、fluentdバッファ状態、セキュリティパッチや
OS更新など
Challenge: スケーラビリティ• 簡単にスケーリングできるようにしたい
• 簡単 = サーバ構築、Ansible流しより簡単
• ログの出力が著しく増えることが想定されないので、オートスケーリングは必須ではない
• ディスク容量やバッファサイズよりスループットベースで パフォーマンスを指定したい
• こちらの方がDevOpsやSREじゃない開発者にとって一番わかりやすい
なぜ 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なログ基盤の構成
• 完全に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の不具合などから
ログを守るためのバックアップが欲しい
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
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
総括
• Kinesis + Lambdaで気軽に拡張可能なロギングアーキテクチャを実現
• Lambda連携で自動リトライ、実装では格納とエラー処理のみで十分
• KinesisとLambdaの活用でServerless構成、メンテナンスコスト減
• 共通化、OSS化によって導入コスト減
top related