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

Slide 1

Slide 1 text

2023年2月16日（木） 18:00開始予定開始までしばらくお待ちくださいインフラを横断して可視化するダッシュボードの開発

Slide 2

Slide 2 text

※ あくまでこの会の趣旨を表現しており、実際の開発でこの発言があるわけではありませんインフラを横断して可視化するダッシュボードの開発

Slide 3

Slide 3 text

株式会社メタップスのエンジニアチームが中心となり、新規事業やスキルの話からITフリーランスの仕事事情まで、 WeWorkのエンジニアの皆さんを巻き込んでタイトルの通り、ゆる〜くトークするイベントです。

Slide 4

Slide 4 text

外部の方もスピーカーとして参加してもらいたい・・・ WeWorkのオープンスペースでビール片手にまったり楽しんでもらえるエンジニアイベントです！他社のエンジニアと合同で企画をたてていきたい・・・ WeWorkに来るエンジニアのみなさんと仲良くなりたい！

Slide 5

Slide 5 text

チャンネル登録・高評価お願いします！メタップス | Metaps

Slide 6

Slide 6 text

主催株式会社メタップス

Slide 7

Slide 7 text

metapsについてファイナンス  マーケティング  DX支援／その他  決済サービスの提供を軸に、   お金×テクノロジーに関わる事業を   総合的に展開   広告配信、販促最適化まで   デジタルマーケティングを   ワンストップで支援   企業のDXを支援するSaaSや   開発チームのマッチングサービスを   提供 

Slide 8

Slide 8 text

スピーカー紹介山北尚道ベトナム・ハノイでのオフショア事業立ち上げからキャリアをスタートし、アプリケーション開発からマネジメントまでを経験。 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-ﬂash/202210/metaps-monitoring-dashboard-development/ Naomichi YAMAKITA

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

1.数値で見るSRE 

Slide 11

Slide 11 text

SWE  58人 

Slide 12

Slide 12 text

SRE  5人 

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

機能改善  329件 / 1,300日 

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

オンコール  4回 / 月 

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

SREの責務 

Slide 21

Slide 21 text

今回はココ 

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

運用の自動化を図る 

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

No content

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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 メトリクスソースを管理する 

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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にデータを渡す # 表示する

名前:{{profile.name}}

# 更新する ... Hook Container Presentational

Slide 35

Slide 35 text

BaseComponent/PresentationalComponentに分ける。    ● BaseComponent  ○ あらゆるすべてのページから使うことが想定されるコンポーネント。  ○ Storybookで使い方をカタログ化。    ● PresentationalComponent  ○ 特定のページ、特定のページ群だけで使うコンポーネント。   ○ 可読性のために、部分的に切り出すことや、共通化も許可。     コンポーネントの分け方 

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

● 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

Slide 44

Slide 44 text

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 実行コマンド

Slide 45

Slide 45 text

4.まとめ 

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

No content

Slide 48

Slide 48 text

チャンネル登録・高評価お願いします！メタップス | Metaps

Slide 49

Slide 49 text

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