インフラを横断して可視化するダッシュボードの開発

Transcript

1. 2023年2月16日（木） 18:00開始予定 開始までしばらくお待ちください インフラを横断して可視化する ダッシュボードの開発
2. ※ あくまでこの会の趣旨を表現しており、実際の開発でこの発言があるわけではありません インフラを横断して可視化する ダッシュボードの開発
3. 株式会社メタップスのエンジニアチームが中心となり、 新規事業やスキルの話からITフリーランスの仕事事情まで、 WeWorkのエンジニアの皆さんを巻き込んで タイトルの通り、ゆる〜くトークするイベントです。
4. 外部の方もスピーカーとして 参加してもらいたい・・・ WeWorkのオープンスペースでビール片手に まったり楽しんでもらえるエンジニアイベントです！ 他社のエンジニアと合同で 企画をたてていきたい・・・ WeWorkに来るエンジニアの みなさんと仲良くなりたい！
5. チャンネル登録・高評価お願いします！ メタップス | Metaps
6. 主 催 株式会社 メタップス
7. metapsについて ファイナンス
 マーケティング
 DX支援／その他
 決済サービスの提供を軸に、 
 お金×テクノロジーに関わる事業を 
 総合的に展開 
 広告配信、販促最適化まで 
 デジタルマーケティングを 
 ワンストップで支援 
 企業のDXを支援するSaaSや 
 開発チームのマッチングサービスを 
 提供

8. スピーカー紹介 山北 尚道 ベトナム・ハノイでのオフショア事業立ち上げからキャリアをスタートし、アプリケーション開発か らマネジメントまでを経験。 2015年に株式会社メタップスに参画。徐々にクラウドインフラにも携わり、現在は同社で横断 的なテックリードやSREエンジニアとして従事。 AWS Dev Day Tokyo https://pages.awscloud.com/rs/112-TZM-766/images/G-1.pdf メタップスにおける ECS デプロイ戦略 - AWS https://aws.amazon.com/jp/blogs/news/ecs-deployment-strategy-at-metaps/ メタップスが取り組むシステムの運用状況を可視化するダッシュボード開発 https://aws.amazon.com/jp/builders-flash/202210/metaps-monitoring-dashboard-development/ Naomichi YAMAKITA
9. インフラを横断して可視化する
 ダッシュボードの開発

10. 1.数値で見るSRE

11. SWE
 58人

12. SRE
 5人

13. Platform SREs
 インフラ基盤の構築や開発体験の向上をミッションとし、 横断的に利用可能なプラットフォームの設計・開発を推進する。 
 
 Embedded SREs
 プロダクト開発に参加し、開発チームと連携してシステムの 安定運用・サイトの信頼性向上に取り組む。 
 

14. 監視対象プロダクト
 13サービス

15. 機能改善
 329件 / 1,300日

16. インフラ監視アラート
 224回 / 月

17. オンコール
 4回 / 月

18. ポストモーテム
 1回 / 2ヶ月

19. 2.ダッシュボード開発に至る背景

20. SREの責務

21. 今回はココ

22. • トイルとは
 ◦ 手作業、繰り返される、自動化が可能、戦術的、長期的な価値がない、 サービスの成長に比例して増加する、といった特徴を持つ作業のこと。
 
 • 具体的には
 ◦ サーバーのセキュリティパッチ適用
 ◦ 攻撃元リクエストIPの分析・拒否
 ◦ 監査ログの証跡レポート作成 など
 トイルの削減

23. 運用の自動化を図る

24. Lambda関数の実行結果通知が大量にSlackに届くため、逐一通知内 容を確認する羽目に。
 大量の通知に閉口

25. アジリティの低下
 SREがサポートするプロダクトが増えるにつれ、アラート
 を見逃す傾向が顕著に。
 
 
 
 オブザーバビリティの実現
 AWSやDatadog、Sentryなどから通知されるイベントログを収集し、
 ダッシュボードで可視化する仕組みを構築。

27. 3.ダッシュボードを構成する技術

28. Vue.js
 Lambda
 DocumentDB
 AND Amplify, API Gateway, Serverless Application Repository, Serverless Framework 

29. メトリクスを収集するLambda関数をServerless Application Repository 経由でリリース・デプロイ。
 メトリクスを集める

30. AWSはLambda、DatadogやSentryはWebhook経由でイベントを送信 する仕組みを構築。
 ソース 送信するデータの例 メトリクス配送フロー AWS • GuardDutyの検出結果 • SecurityHubの検出結果 • Inspectorが検知した脆弱性の検出結果 EventBridge -> SQS -> Lambda -> API Gateway Datadog • モニターのアラート • ログのアラート • SLO計測値 Webhook -> API Gateway Sentry • アプリケーションで発生した例外 Webhook -> API Gateway PagerDuty • オンコールイベント Webhook -> API Gateway メトリクスソースを管理する

31. • プロダクトごとのオンコール発生頻度やア ラート、SLO、脆弱性などを横断して監視 できる仕組みを実装。
 
 • ダッシュボードは鋭意開発中。現在はBI ツールからMongoDBに接続する形で試験 運用中。
 
 メトリクスを可視化する

32. ダッシュボードのインフラ構成

33. • フレームワーク
 ◦ Vue.js
 
 • UIライブラリ
 ◦ Vuetify
 
 • ビルド
 ◦ Vite
 
 • グラフ描画
 ◦ Google Chart Tools 
 
 • デプロイ・ホスティング
 ◦ Amplify
 フロントエンドを構成する技術

34. Viewのレイヤー構成
 • Container/Presentational
 データ管理はContainer。データ表示は Presentational。
 
 • Hook
 Container層をスリム化するための共通 APIレイヤー。
 useProfile (例) ・onMountedで、APIのget。結果をprofileに格納する。 ・setProfile関数で、APIでpatch。DB更新する。 ・return { profile, setProfile } # hookからデータのゲッター、セッターを取得 const { profile, setProfile } = useProfile # Presentationalにデータを渡す <ProfileView :profile="profile", :setProfile="setProfile"> # 表示する <p>名前:{{profile.name}}</p> # 更新する <form submit="setProfile(param)">... Hook Container Presentational
35. BaseComponent/PresentationalComponentに分ける。
 
 • BaseComponent
 ◦ あらゆるすべてのページから使うことが想定されるコンポーネント。
 ◦ Storybookで使い方をカタログ化。
 
 • PresentationalComponent
 ◦ 特定のページ、特定のページ群だけで使うコンポーネント。 
 ◦ 可読性のために、部分的に切り出すことや、共通化も許可。 
 
 コンポーネントの分け方

36. GoogleChartsを採用
 Google Charts Highcharts Chart.js 基本的な描画 ◦ 
 (svg)
 ◦ 
 (svg)
 ◦ 
 (canvas)
 マウスホバーの強調表示 ◦
 ◦
 △
 グラフ中の要素にイベント ◦
 ◦
 ×
 細かなデザイン調整 ◦
 ◦
 △
 ドキュメントが充実 ◦
 ◦
 ◦
 無料 ◦
 ×
 ◦
 グラフ描画ライブラリの選定

37. アプリケーションのビルドからデプロイ、ホスティング、スケールまでフ ルマネージドで提供するサービス。
 
 • 自前でS3バケットやCloudFrontディストリビューションの準備が不 要。
 Amplify

38. • API管理
 ◦ API Gateway
 
 • 認証
 ◦ Cognito
 
 • アプリケーション基盤
 ◦ Lambda
 
 • フレームワーク
 ◦ Serverless Framework 
 
 • 配信
 ◦ Serverless Application Repository 
 バックエンドを構成する技術

39. • API GatewayにてAPIキーを発行し、デー タエンドポイントにはLambdaで実装した Request Authorizerをアタッチする。 
 
 • 認可にAPIキーを利用することで、プロダ クトごとにAPI使用量の計測や、スロットリ ング制限が可能。
 イベントデータ収集基盤の認証

40. • ユーザー管理にはCognito User Poolsを 採用。ユーザーIDを保護するため2要素 認証 (TOTP) を必須化。
 
 • API Gatewayの各エンドポイントにCognito User Pool Authorizerをアタッチ。
 
 • Amplify SDK (Auth) 経由でCognitoに認可 を求め、JWTを利用してAPI Gatewayにリ クエストを送信。
 ダッシュボードAPIの認証

41. • API Gatewayはイベントデータ受信後、DocumentDBにデータを登録す る。
 
 • DocumentDBはAWSが提供するJSONドキュメント指向データベース。
 ◦ MongoDBとの互換
 ▪ MongoDB 3.6/4.0系互換API対応。 
 
 ◦ フルマネージド
 ▪ オートスケール、自動パッチング、S3へのストリームバックアップなど。 
 
 ◦ 高パフォーマンス
 ▪ ストレージとコンピュートノードを分離し、高いパフォーマンスを実現。 
 データストレージ

42. • API Gatewayは毎秒数千以上のリクエストを捌き、データベース に書き込む必要がある。
 ◦ 高スループット、低レイテンシを重視。
 ◦ DocumentDBであれば、秒間100万リクエストを実行可能。
 
 • ログデータの特性上、データ構成は柔軟に変更できることが望ま しい。
 ◦ スキーマレスを重視。
 ◦ MongoDB互換APIを備えており、データ検索や集計も柔軟に対応可 能。
 DocumentDBを採用した理由

43. • Lambda (Ruby) を採用。
 
 • MITは通知やロギング、コンフィグレーショ ンなどを提供する軽量フレームワーク (Lambda Layer)。
 アプリケーション基盤
 class HelloWorld < Mit::Function::Base def run fields = { 'Greeting' => I18n.t('greeting') } Hello.create(fields) Mit::Notifier.send(I18n.t('subject'), fields) create_response end Firework Edge sample
44. Serverless FrameworkからServerless Application Repositoryにアプリケーションを配 布するプラグインを実装。
 
 
 
 
 
 
 アプリケーションのインストールは、 CloudFormationやTerraformでIaC化することが 可能。
 アプリケーションの配布
 docker-compose run --rm sls publish --config serverless-firework.yml --stage production --function ec2-security-update --semantic-version=0.12.7 実行コマンド
45. 4.まとめ

46. ダッシュボード開発で生まれたメリット
 • 定例でダッシュボードをチェックする体制を整え、普段のアラート 対応で見逃しがちな問題を早期検知することが可能となった。
 
 • アラート (オンコール) を減らすことを目的として作られたプロダク トのため、ドッグフーディングにより自分たちの業務を効率化する ことができた。

48. チャンネル登録・高評価お願いします！ メタップス | Metaps
49. https://lp.re-shine.jp/ 副業エンジニア・フリーランスエンジニア向けの マッチングプラットフォームです。 ぜひ一度登録してみてください！ リシャイン 検索 ご清聴ありがとうございました。