【レポート】暗号資産(仮想通貨)取引所を支えるサーバーレスログ基盤の裏側 #AWSSummit

どうも、もこ@札幌オフィスです。

今年はAWS Summit Onlineという事で、2020/9/8〜9/9の間のライブセッションと、09/30まで視聴可能なAWS認定セッション、お客様事例セッション、セルフペースハンズオン、Partner Discovery Session (パートナーセッション) などなど、場所を選ばずにオンラインで、好きな時に好きなだけ学べるような環境になっています。

本記事はオンデマンドセッション「暗号資産(仮想通貨)取引所を支えるサーバーレスログ基盤の裏側」のセッションレポートとなります。

セッション情報

ビットバンク株式会社 システム部 エンジニア 谷津 香 氏

ビットバンク株式会社は 24 時間 365 日の高い稼働率が求められる 日本の金融庁登録済の暗号資産(仮想通貨)取引所です。 Web サービスとしての開発のスピード感と金融機関としてのセキュリティ・ガバナンスの両立が欠かせません。 それらを達成するために、アプリケーションの異常時のトレースで必要となるアプリケーションログと セキュリティに関する要件で必要なログの収集、分析、リアルタイム性のある可視化環境が整備されておらず、 セキュリティ・ガバナンスとしてのモニタング、セキュリティログの分析ができていないことが課題となっていました。 この課題に対して、現状のアプリケーション構成を変えずに導入が可能なマネージドサービスである Kinesis Stream, Analytics, Firehose を採用しました。 導入の結果、アプリケーションログ及びセキュリティログの分析、リアルタイム性のある検知と可視化が可能となりました。 これにより、従来のログ検知までのリードタイムを維持しながら迅速なエラー原因の特定や 本番変更作業のログモニタリングが可能となりました。 さらにログ連携環境を CloudFormation で構築することで迅速なアプリケーション連携を実現しています。

セッションレポート

• ビットバンク株式会社
  • bitbank.cc のサービスを提供
• アジェンダ
  • ログ基盤が出来る前
  • 課題
  • どのように解決していったか
  • アーキテクチャ
  • 新たに見えてきた課題
  • 今後の取り組み
  • まとめ
• 今回話すこと
  • AWSのマネージドサービスを活用してログ基盤を構築した事例
  • 組織上の制約、ログ基盤に求めたものにたいしてAmazon Kinesis Familyでどのように解決したのかをご紹介

ログ基盤が出来る前、課題

• 前提
  • 全サービスをAWS上に構築してログを取得している
  • AWS Fargate, AWS ElasticBeanstalkなどをCloudWatch Logsに集約
  • AWS CloudTrailのほか、Amazon Aurora監査ログをCloudWatch Logsに入れている
  • マルチアカウントの管理も行っている
• AWSアカウント管理ではAWS Organizationを活用してOUごとに本番、ステージング、開発環境などにアカウントを別けている
  • 統制、請求、コスト管理、ログ管理、アプリケーション、データなど用途ごとにアカウントがある
  • 以前の構成ではアプリケーションログはCloudWatch Logsに出力して、LambdaでSlack通知
  • エラーが合ったらCloudWatch Logsを見に行って調査を行っていた
  • セキュリティー監査ログではAuroraDB Userのクエリログを取得
  • CloudWatch Logsの目検でチェックしていた
• 課題
  • ログ分析が出来ない
  • 監査要件でのログ抽出に手間が掛かっていた
  • 高度なリアルタイムアラートが出来ていなかった
• ログ基盤に求められた物
  • 運用
    • 負荷を限りなく少なくすること
    • NoOps化
  • 分析・通知
    • 分析しやすいログ形式で保存
    • リアルタイム性を損なわないこと
    • 高度な分析が出来ること
  • 再現性
    • 既存の環境を壊すこと無く移行
    • 構成をコードで管理

どのように解決していったか

• 設計するに当たって次の点を指針とした
  • NoOps化
    • 運用に当たって人手が必要な作業をできるだけ最小限にすること
  • ポータビリティ
    • 事業がスケールすればするほどそれに合わせてアプリケーションなどのログが増えていく
    • それらをできる限り迅速にログ連携できること
    • 他環境(開発環境、ステージング環境、本番環境など)に簡単にログ連携出来ること
  • 既存の環境への影響を最小限に
    • すでに稼働しているアプリケーションに影響ができないこと
    • もし影響があった場合、切り戻しが容易があること
• 利用したKinesis Family
  • Amazon Kinesis Data Streams
  • Amazon Kinesis Data Firehose
  • Amazon Kinesis Data Analytics
• Amazon Kinesisを採用した理由
  • Amazon Kinesis Data Streams
    • CloudWatch Logsをソースにしたクロスアカウント連携に対応
    • スケールが出来るため管理が容易
    • 他のKinesisと組み合わせて使うときの入り口として利用
  • Amazon Kinesis Data Firehose
    • Amazon S3にデータを時系列順における
    • データをLambdaで加工できるので分析しやすい形で配信出来る
    • ログ分析ツールとの親和性が高い
      • S3だけではなく、SplunkやElasticsearchなどに配信することが可能
  • Amazon Kinesis Data Analytics
    • 処理時にLambdaと組み合わせて利用
    • リアルタイムに分析が可能
    • SQLを用いてデータのクエリを柔軟に設定出来る
• Amazon SQSを使わずにAmazon Kinesisにした理由
  • SQSを使った場合に考慮しないといけない点がいくつかある
    • ログが急増した場合処理が遅延してしまう
      • 暗号資産取引所の場合、相場の変動の影響でバーストトラフィックが発生する
    • 既存環境を壊さないように設計すると構成が複雑に
      • Slack通、フィルターの実装、ログ加工、S3に時系列保存など、Lambdaの実装が肥大化したり工夫が必要になってしまうため、バグの温床になりかねない
    • LambdaがQueueに入れるときのログの順番の保証が出来ない
  • Lambdaにより実装と管理対象を減らしたかった
  • Kinesisを使うことでこれらの問題を解決

アーキテクチャ

• Fargateを使ったパターン
  • awslogsログドライバーを利用してCloudWatch Logsに出力
  • CloudWatch Logs SubscriptionでKinesisと繋ぎ
  • Kinesis Data Streamで宛先を複数指定
  • Kinesis Data Analyticsでリアルタイム分析を行う
  • Kinesis Data FirehoseではS3に配信

• ElasticBeanstalkを使ったパターン
  • CloudWatch Agentを使ってCloudWatch Logsにログを送信
  • それ以降の流れはFargateと同じ

• Lambdaのパターン
  • 標準出力がCloudWatch Logsに送信される
  • LambdaについてはSlack通知の用途が無かったのでAnalyticsは使っていない

• Auroraのパターン
  • Amazon Auroraの方で監査ログをONにして、CloudWatch Logsに出力される
  • Kinesis Data Firehose内でLambdaを呼び出してJSONにパースしてS3に配信

• CloudWatch LogsからKinesis連携を行う時のTips
  • CloudWatchからログイベントが転送される際に logEvents 内に複数入ってくるので必要に応じて分解
  • データがbase64/gzip圧縮されているので加工したい場合デコード、解凍を行ってから処理をする
  • LambdaのBluePrintというテンプレートが用意されているので、一から開発する必要は無い
• AWS CloudFrontmationによる環境構築
  • AWS環境をコードで管理するIaCの実現
  • 環境の再現性を重視していたので、開発、ステージング、本番環境へのマルチアカウントへのデプロイが柔軟に、管理が楽に
  • ドリフト検知で、変更のトラッキングも出来て、運用時の構成変更もCloudFromationのアップデートを行うことで簡単に
  • 手作業で行う際のヒューマンエラーの回避、運用負担の軽減が出来て、NoOps化出来た
    • CloudFormationが無かった場合
      • 環境構築に時間が掛かる
      • 全部手作業
      • 詳細な手順書、ドキュメントも大量に必要
      • 構成管理も出来ない
• 移行時
  • CloudFormationを利用していたので、手作業が最小限に
  • Subscription Filterを切り替えるだけのリリースだったのでスムーズに移行出来た
  • 本番環境への影響が無かった
• ログ基盤の導入により改善されたこと
  • S3にログを保管することでログ分析が可能になった
    • アプリケーション性能の調査をログから行うのは難しかったが、調査をログドリブンで行うことが容易に
    • エラー発生時の原因ログ調査も、CloudWatch Logsを直接見ること無く行えるようになった
    • ログが必要な問い合わせ時の調査も、CloudWatch Logsを担当者が見ること無く提供出来るようになった
    • 監査業務にかかる時間も、分析しやすい形のログ提供で大幅に短縮
  • 高度なリアルタイムアラートが可能に
    • SIEMと連携ができ、リアルタイムで検知出来るように
  • マネージドサービスとサーバーレス化による運用軽減でNoOpsの実現

新たに見えてきた課題

• CloudFroamtionのデプロイは人間が行っている
  • すぐにログ連携が出来るとは限らないので、多少の待ちが発生してしまう
  • 監査の観点上、作業申請が必要
  • ステップが煩雑、人間の本番作業をできるだけ減らしたい
  • 爆速にデリバリーしたい
    • →よろしい、ならば自動化だ

今後の取り組み

• 連携の仕組みを自動化してCloudFormationのデプロイに人を通さないようにしたい

• まとめ
  • 基盤にKinesis+Lambdaを使うことで、既存の環境を壊さずに移行出来た
  • Kinesisが組み合わせて使えるので拡張性が広がった
  • CloudFormationを使うことで運用不可を下げて、NoOps化を実現出来た
  • 今後の課題が出てきたので、もっと爆速にデリバリーしていく
  • 今後の取り組み、AWS、ビットコイン、ミッションクリティカルなインフラに興味がある方はエンジニア採用を行っているので検索！

感想

既に出力しているCloudWatch LogsからSubscription Filterを利用して既存環境の構成を変更することなくログの蓄積、分析に使える環境を用意できた素晴らしい例だと思いました。

ミッションクリティカルな環境ほど構成変更を行う際に煩雑な申請や手順が必要な事が多いかと思いますが、今後のデリバリー改善などにも期待です！