Deep dive into cloud design

Slide 1

Slide 1 text

Deep dive into cloud design White paper version 1

Slide 2

Slide 2 text

● 本資料はメタップスの開発者向けに、開発者自身が関わるプロダクトのインフラ構成や、クラウド設計の理解を深めるための資料となります ● 資料のボリュームが大きいため、勉強会の場では重要な箇所をピックアップして解説します ○ ログの調査方法やコードスニペットも含まれるため、資料自体をブックマークしておくことをお勧めします。資料の内容は随時アップデートします。はじめに 2

Slide 3

Slide 3 text

SREはSite Reliability Engineeringの略称です 3

Slide 4

Slide 4 text

? 4

Slide 5

Slide 5 text

https://cloud.google.com/sre 5

Slide 6

Slide 6 text

6 SRE は、信頼性の高い本番環境システムを実行するための職務、マインドセット、エンジニアリング手法のセットです。 Google Cloud では、ツールやプロフェッショナルサービスなどのリソースを通じて、SRE の原則を実装できるよう支援しています。

Slide 7

Slide 7 text

? 7

Slide 8

Slide 8 text

ChatGPT 8

Slide 9

Slide 9 text

SREは「Site Reliability Engineering」の略で、Googleが開発した運用の手法です。ソフトウェアシステムの信頼性、スケーラビリティ、効率性を確保するための工学的手法を用いてシステムを管理・運用する役割を指します。 SREの目的は、サービスを持続可能な方法で高速に提供すること、そして障害が発生した場合でも迅速に復旧できる能力を確保することです。 9

Slide 10

Slide 10 text

SREユニットの紹介 10 Introduction to the SRE Unit

Slide 11

Slide 11 text

● メタップスグループにおけるインフラ運用のエキスパート ○ インフラ基盤の設計・構築をはじめ、運用の自動化、オンコール、開発支援、パフォーマンス分析、セキュリティ施策といった様々な幅広い知識と、システムを俯瞰した視点から課題や改善点を見出すスキルが求められる ● Dev/Opsプラットフォームの開発 ○ プロダクトを横断した組織として、共通基盤となる強固な Dev/Opsプラットフォームを構築。各社で培ったノウハウを取り入れつつ、定常的なインフラ改善、安定した運用に取り組む SREユニットのミッション 11

Slide 12

Slide 12 text

ユニット体制 12

Slide 13

Slide 13 text

● 何をやってるのか ○ インフラ設計・運用・構成アップグレード ○ クラウド基盤へのアプリケーションの統合 ○ CI/CDの構築 ○ クラウドネイティブ設計のサポート ○ トイルの削減 (運用の自動化) ○ 監視・SLO ○ オンコール・ポストモーテム ● 各プロダクトのAWS運用は専属のEmbedded SREが担当しますユニット体制 - Embedded SREs 13

Slide 14

Slide 14 text

● 何をやってるのか ○ DevOps基盤の構築 (IaC、CI/CD) ■ 技術スタックの選定、基盤となるプラットフォームの開発 ○ SRE:shineの開発 ■ アラートを監視するダッシュボードの導入ユニット体制 - Platform SREs 14

Slide 15

Slide 15 text

● 各プロダクトごと月に数本の機能アップデートを実施 ● ベースとなるWebアプリケーション環境で安定動作が確認された機能順次横展開していますインフラ構成のアップデート 15

Slide 16

Slide 16 text

● github.com/naomichi-y/cloudwatch_logs_insights_ur l_builder (Go) CloudWatch Insights URLビルダー ● github.com/naomichi-y/docker-fluent-logger (Ruby) RailsのログをFluentd向けに変換 ● github.com/naomichi-y/cloudwatch-logs-downloader (Go) CloudWatch Logsをローカルにダウンロードする ● AWS Serverless Application Repository (Ruby) トイルを削減するユーティリティの提供 (準備中) SREユニットではOSS活動を推進しています 16 ● github.com/metaps/genova (Rails) ECSデプロイツール ● github.com/metaps/action-dependabot-auto-merge (YAML) GitHub Actions向けのDependabot自動マージアクション ● github.com/metaps/connect_to_fargate (Python) Fargateコンテナ接続ユーティリティ ● github.com/metaps/action-genova (YAML) GitHub Actions向けのgenovaデプロイアクション ● github.com/naomichi-y/aws-assume-role (Go) STS発行ユーティリティ

Slide 17

Slide 17 text

SREユニットが提供する技術スタック 17 Technology Stack Offered by the SRE Unit

Slide 18

Slide 18 text

インフラ基盤の基本構成 18 ● SREチームが提供する社内共通基盤は次の通りです ○ GitHub ○ AWS ○ Datadog ○ Sentry ○ PagerDuty ● 各事業体で独自に採用しているSaaS/PaaSもありますが、原則的にはSREチームでアカウントを管理し、可能な限りIaCベースでインフラを構築しています ○ Deep Security ○ GCP ○ SendGrid ○ Firebase など

Slide 19

Slide 19 text

権限の移譲 ● 各事業体の開発マネジャーにはSaaS/PaaSのフルアクセス権限を付与していますが、原則的にSREユニットが管理する基盤の設定変更は担当SREに依頼してください ○ SREユニットではリソースの状態管理を統一するべく、 IaCをベースにコード管理しています ○ 一時的な検証における設定変更は問題ありません ○ 急ぎの作業などでマネジャー側で設定を変更した場合は変更内容を担当 SREに共有してください。変更内容が共有されていない場合、コードの上書きによって設定がロールバックされる恐れがあります 19

Slide 20

Slide 20 text

● リポジトリの作成・ユーザーの追加、削除など ○ 担当SREに依頼してください ● Code Copilot ○ 9月頃に申請ベースで利用可能となる予定です。詳細は追ってアナウンスします ○ 利用者は運用ガイドラインを一読してください GitHub 20

Slide 21

Slide 21 text

● Q: GitHubの通知をSlackで受け取るには? ○ 各プロダクトのgithubチャンネルに参加することで、 GitHub上のメンションをSlackで受け取ることができます ○ チャンネルへの参加は開発マネジャー、あるいは担当 SREにご連絡ください GitHub 21

Slide 22

Slide 22 text

● Slack連携方法 ○ Slackを開き、左ペインから [Apps] の右横にある [+] を選択 ○ アプリ一覧から GitHub を検索して、表示されたアプリを選択 ○ GitHubとの連携ボタンが表示されるので、 [Connect GitHub account] ボタンを押下 ○ OAuthのページが開くので、 [Connect GitHub account] ボタンを押して、SlackとGitHubを連携させる ● 動作確認 ○ GitHub Issue上で自分のGitHubアカウントにメンションしたとき、 OSから通知が届けば連携が成功しています GitHub 22

Slide 23

Slide 23 text

● CI/CD基盤にはGitHub Actionsを利用しています ○ 1ヶ月あたりおよそ133時間のテストが走ってます (2023年7月の統計) ● テストを高速化するために ○ テストを並列実行する ■ ジョブにマトリックスを使用する ○ パッケージのインストールはキャッシュする ■ 依存関係をキャッシュしてワークフローのスピードを上げる ○ 高速なビルドツール、テストツールへの移行 ■ Turbopack、Vitestなど ○ テストランナーの変更 GitHub Actions 23

Slide 24

Slide 24 text

● メタップス全プロダクトの基盤となるインフラです ● SREユニットでは Well-Architected に準拠した設計を目指しています ● インフラの新機能検証や導入は原則re:shine環境がベースとなっています ○ re:shineはFTR (AWS Foundational Technical Review) を取得してます ○ FTRとは? ■ AWS パートナーのソフトウェアまたはソリューションがセキュリティ、信頼性、運用上の優秀性に関連する AWS ベストプラクティスに沿っていることを確認し、リスクを特定して修正するための技術レビューです。 ...(中略) AWS パートナーネットワークでソフトウェアパスに参加して FTR を通過したソフトウェアまたはソリューションは、「 AWS 認定ソフトウェア (AWS Qualified Software)」として正式に認められます AWS 24

Slide 25

Slide 25 text

Datadog ● アプリケーション・インフラの監視サービス ● 主に次のサービスを利用しています。開発メンバーはLog、APMの使い方を習得してください (後述) ○ Monitor ■ メトリクスのしきい値を監視し、異常が検知された場合は Slackに通知。重要度の高いアラートはPagerDutyにエスカレーション (本番環境のみ) ○ Synthetic ■ HTTPやgRPCによるWebアプリケーションの外形監視 (本番環境のみ) ○ Log ■ アプリケーションログの収集と検索を提供 ○ APM ■ アプリケーションのパフォーマンスを分析 25

Slide 26

Slide 26 text

● アプリケーションのエラートラッキングツールです。アプリケーション発生した例外を Sentryでキャプチャすることで、例外ごとの発生頻度やエラーの詳細をSentryのダッシュボードで確認することができます ● 例外が発生した際は、各プロダクトのSlack チャンネルにアラートを通知する仕組みを導入しています ○ チャンネル名: {プロダクト名}-sentry ● Sentryのアラートは現在のところオンコール対象外です。各プロダクトの開発マネジャーは、チーム内でアラートを監視する体制を構築する必要があります Sentry 26

Slide 27

Slide 27 text

Sentry 27

Slide 28

Slide 28 text

● インシデント管理ツールです。DatadogやSentryなどのSaaSからエスカレーションされた障害をオンコール担当者に通知することができます ● SREユニットではメンバー全員がオンコールに参加しており、社内外のインフラを24/365体制で監視しています ● 代表的なオンコール対象メトリクスの例 ○ アプリケーションがHTTP 5xxを返した ○ 外形監視が失敗 ○ ヘルスチェックが失敗 ● オンコールとしないメトリクスの例 ○ ネットワークレイテンシーの上昇 ○ CPU、メモリなどのリソース使用率上昇 PagerDuty 28

Slide 29

Slide 29 text

PagerDuty 29

Slide 30

Slide 30 text

● データベースを可視化するBIツールです。GUIベース、あるいはネイティブクエリでダッシュボードを作成することができます ● Metabaseからは本番のデータベース (レプリカ) を参照します。負荷対策のためビューは一定時間キャッシュされます ○ 最新のデータを取得したい場合はクエリベースでデータを取得してください Metabase 30

Slide 31

Slide 31 text

Metabase 31

Slide 32

Slide 32 text

● VPNが必要な開発者にはOpenVPNのアカウントを発行しています OpenVPN 32

Slide 33

Slide 33 text

● IPS (不正侵入防御)、IDS (不正侵入検知) の役割として、一部のプロダクトではトレンドマイクロ社のCloud Oneを導入しています ● Cloud One Workload Securityを導入することで、不正プログラム対策 (マルウェア) や不正な通信をネットワークレベルで遮断することが可能となります ○ Workload SecurityはAmazon EC2を保護します。サーバーレス環境 (FargateやLambdaなど) はサポート対象外となります Cloud One Workload Security 33

Slide 34

Slide 34 text

Cloud One Workload Security 34

Slide 35

Slide 35 text

インフラ基盤の基本構成 35

Slide 36

Slide 36 text

アプリケーション設計 36 Application design

Slide 37

Slide 37 text

● モダンなWebアプリケーションのあるべき姿を12のベストプラクティスにまとめた方法論。必読です ○ https://12factor.net/ja/ ● Beyond the Twelve-Factor App ○ 2016年に発表されたTwelve Factor Appのアップデート版 THE TWELVE-FACTOR APP 37

Slide 38

Slide 38 text

THE TWELVE-FACTOR APP 38 1. コードベースバージョン管理されている 1つのコードベースと複数のデプロイ 2. 依存関係依存関係を明示的に宣言し分離する 3. 設定設定を環境変数に格納する 4. バックエンドサービスバックエンドサービスをアタッチされたリソースとして扱う 5. ビルド、リリース、実行ビルド、リリース、実行の 3つのステージを厳密に分離する 6. プロセスアプリケーションを 1つもしくは複数のステートレスなプロセスとして実行する 7. ポートバインディングポートバインディングを通してサービスを公開する 8. 並行性プロセスモデルによってスケールアウトする 9. 廃棄容易性高速な起動とグレースフルシャットダウンで堅牢性を最大化する 10. 開発/本番一致開発、ステージング、本番環境をできるだけ一致させた状態を保つ 11. ログログをイベントストリームとして扱う 12. 管理プロセス管理タスクを1回限りのプロセスとして実行する

Slide 39

Slide 39 text

フロントエンド開発 ● Webパフォーマンスを意識して実装を行ってください ○ Lighthouseや PageSpeed Insights でアプリケーションのパフォーマンスを計測してください ○ RUM (Real User Monitoring) を導入することで、UX分析やエラー分析、パフォーマンス分析が可能となります (例: Sentry Performance Monitoring、Datadog RUMなど) ● アンチパターンの例 ○ アセットがCDNから配信されていない ○ アセットが圧縮 (あるいはバンドル) されていない ○ 適切な画像フォーマットやリサイズが適用されていない ○ SPAで起こりやすい問題 ■ 構成されたアプリケーションがリロード時に HTTP 304を返している (HTTP 200を推奨) ■ 同一エンドポイントに多重リクエストが実行されている ■ APIの例外が捕捉されず、画面全体の挙動に影響が発生 39

Slide 40

Slide 40 text

● 秘匿値はソースコードに埋め込まないでください ○ 秘匿値とは、AWSのアクセスキー、APIのトークン、パスワード情報といったクレデンシャル情報を指します ○ 誤ってコードに埋め込んだ場合、 git filter-repoコマンドなどを用いてすべてのリポジトリ履歴からコードの削除を行ってください ● 秘匿値の管理はParameter Store、またはSecrets Managerの利用を推奨 ○ ECSを利用する場合、環境変数に Parameter Store/Secrets Managerのキー埋め込むことができます ■ https://github.com/metaps/genova/wiki/Encryption-of-environment-variables ● AWS SDKのインストール ○ パッケージは非常に大きいので、必要な SDKのみ組み込むようにしてください ■ イメージの肥大化や、ビルド・テスト実行時間に影響が出ますバックエンド 40

Slide 41

Slide 41 text

バックエンド 41 ● 通信のタイムアウト ○ アプリケーションがELB配下で動作する場合、アプリケーションのタイムアウトは ELBのタイムアウトに依存する点に注意が必要してください (デフォルト60秒) ○ CSVファイルのダウンロードなど実行に時間がかかる処理は、メッセージキューの導入を検討してください ○ アプリケーションが外部と通信する際は、接続タイムアウトを考慮してください。通信中はアプリケーションのスレッドが専有されることを意識しましょう ● データベースアクセス ○ デッドロック、行ロックは Datadogアラートで検知します。アラート発生時は SRE側で一次調査を行います ○ スローログに関しては 1秒以上かかるクエリを CloudWatch Logsに記録しています (後述) ○ クエリのパフォーマンスは、 Datadog APMからも確認することができます (後述)

Slide 42

Slide 42 text

● 接続の再試行 (Exponential Backoff) ○ 外部サービスと通信する際は、ネットワークや相手側のサーバーの問題で、一時的に接続が不安定になる可能性があります。一定時間内にレスポンスがない場合は再試行する仕組みを検討してください ● アンチパターンの例 ○ N+1 (後述しますが、Datadog APMから確認可能です) ○ 画像アップロード機能からアップロードされたファイル名が、サーバー側でリネームされず、オリジナルの名前でアクセスできてしまう (例: スクリーンショット.png) ○ 画像が圧縮・リサイズされておらず、フロントエンドで画像一覧を表示する際のパフォーマンスが低い ○ ファットなAPIレスポンス (モデルデータをそのまま JSONに変換) ○ URLパラメータを書き換えることで、本来権限のないページにアクセスできてしまうバックエンド 42

Slide 43

Slide 43 text

● 常に最新のミドルウェアやパッケージを利用してください ● ビルドに時間がかかる場合、ベースイメージの作成を検討してください ○ DockerHubやECRにベースイメージを登録しておくことで、アプリケーションビルドにかかる時間を高速化することができます # RedHad RUN yum update -y # Debian RUN apt-get update && apt-get upgrade # Alpine Linux RUN apk update && apk upgrade Dockerfile 43

Slide 44

Slide 44 text

● Q: コンテナの起動が遅い ○ マルチステージビルドを検討してください ○ コンテナ起動直後から ELBによるHTTPヘルスチェックが走ります。サーバーの起動に時間がかかるとヘルスチェックが失敗し、コンテナが終了する恐れがあるので注意してください ■ コンテナ起動直後のヘルスチェック猶予期間はデフォルトで 300秒です。 Dockerfile 44

Slide 45

Slide 45 text

● IPアドレスの制限 ○ 外部から内部への通信 ■ 外部ベンダーからリクエストを受け付ける APIエンドポイントを提供する場合、リクエスト送信元 (ベンダー) のIPアドレスが静的なものか確認し、可能な限り接続元の制限を行ってください ■ IPアドレスはネットワークレベルでの遮断が望ましいため、ロードバランサー (WAF) 側での制御を推奨とします。 IPアドレスの制限依頼は担当 SREにご連絡ください ○ 内部から外部への通信 ■ 接続先のベンダーによっては接続元の IPアドレスが制限される場合があります。 AWS内のサービスがインターネットに出る際の送信元 IPは固定となるため、SREから共有されたIPアドレスを案内してくださいバックエンド 45

Slide 46

Slide 46 text

● アプリケーションのメンテナンス ○ アプリケーションのリリース要件や、インフラ基盤のアップグレード要件に伴い、アプリケーションをメンテナンスモードに切り替えるケースがあります ○ メンテナンス期間中はクローラー対策として HTTPステータスは503を返してください。 ■ APIエンドポイントはJSON形式でエラーを返す実装を推奨します ○ メンテナンス切り替えはアプリケーション側で実装するか、インフラで切り替えるか、システムの特性に合わせて検討が必要ですバックエンド 46 切り替え方法メリットデメリットインフラ (ELB) ・アプリケーションレベルでの実装が不要・システム全体で一貫した切り替えが可能複雑な条件でのメンテナンス切り替えは難しい可能性があるアプリケーションより細かいアクセス制限が可能・複数のサービスで構成される場合、メンテナンスデプロイに時間がかかる・インフラ基盤側の障害に対応できない

Slide 47

Slide 47 text

● 障害が発生した際のユーザー告知フローをあらかじめ決めておいてください ○ 告知テンプレートの作成 ■ 初期告知・更新告知・復旧告知 ○ 障害発生時のエスカレーション ■ 例: エンジニア→マネジャー→ 事業責任者による判断 → 広報・CSからの情報配信 ○ 告知チャンネル ■ サイト内での告知 ■ メール配信 ■ 社内アナウンス (Slackなど) ■ SNS (Facebook、Xなど) 障害発生時のアナウンス (開発マネジャー) 47

Slide 48

Slide 48 text

● SREユニットではシステム障害が発生した際、事後分析としてポストモーテム会を実施しています。事後分析の目的はインシデントを文書化した上で、根本となる原因を理解し、再発の可能性や影響を低減することを目的とします ○ ポストモーテム会への参加は、開発・ SREメンバー、開発マネジャー・事業責任者となります (障害の重大度による) ● SREユニットが主催するポストモーテム会のガイドライン ● 過去に発生した障害、及びポストモーテムドキュメントポストモーテム会の実施 48

Slide 49

Slide 49 text

AWSを用いたアプリケーション開発 49 Application development with AWS

Slide 50

Slide 50 text

AWSの操作方法 - コンソール ● WebからログインしてAWSの全てのサービスにアクセスすることができます ● リソースの操作は画面ベースで変更可能です。その反面、設定変更などのレビューが難しい側面があります (👉👮) ● 一部の操作はGUIから行うことができません 50

Slide 51

Slide 51 text

● awsコマンドを用いてリソースを操作します ● コマンドベースの操作となるため、変更内容をレビューしやすいメリットがあります ● AWSコンソールより迅速にリソースの状態を確認すること可能です AWSの操作方法 - CLI 51 $ aws s3 ls

Slide 52

Slide 52 text

● アプリケーションからAWSのリソースを操作するにはAPIを使います ● SREユニットが採用しているTerraformも内部的にはAWS APIをコールしています AWSの操作方法 - API 52 client = Aws::S3::Client.new client.list_buckets.buckets.each do |bucket| # ... end

Slide 53

Slide 53 text

● Q: AWSをコマンドラインから操作するには? ○ AWS CLI を利用してください ● Q: メタクラを利用していますが、どのようにアクセスキーを発行すれば良いですか? ○ 現状アクセスキーの発行には対応していません。必要に応じて個別に IAMアカウントを発行します ● Q: awsコマンドを実行するとAccess Deniedと言われます ○ AWSコンソールでMFAを登録後、STS (Security Token Service) 経由で一時的なクレデンシャルを発行してください ■ MFA トークンを使用して、 AWS CLI を通じて AWS リソースへのアクセスを認証するにはどうすればよいですか? ○ もう少し簡単に ■ https://github.com/naomichi-y/aws-assume-role CLI 53

Slide 54

Slide 54 text

CLI - MFAの登録 54 ● IAMアカウントでAWSコンソールにログイン後、右上のメニューから [セキュリティ認証情報] を開き、[多要素認証 (MFA)] から仮想デバイス (Google Authenticatorなど) を登録してください。発行された識別子を控えておきます ● 同じページ内の [アクセスキー] から [アクセスキーを作成] を選択してアクセスキーを発行してください。クレデンシャル情報ですので扱いには注意が必要です

Slide 55

Slide 55 text

CLI - aws-assume-role (セットアップ) 55 $ ~/.aws/credentials # 接続先AWSアカウントのプロファイル名。プロダクトを識別できる分かりやすい名前を付ける [reshine] aws_access_key_id=[アクセスキー] aws_secret_access_key=[シークレットアクセスキー] mfa_serial=[MFA識別子] duration_seconds=43200 $ vi ~/.aws/config # プロダクトプロファイルの末尾に'-assume'を付けた名前を指定 [profile reshine-assume] region=ap-northeast-1 output=json # aws-assume-roleのインストール $ brew tap naomichi-y/aws-assume-role $ brew install naomichi-y/aws-assume-role/aws-assume-role

Slide 56

Slide 56 text

# STSを発行するプロファイルを指定 $ aws-assume-role AWS profile [default]: reshine Token code: 101765 Access key ID: *** Successfully updated reshine-assume profile. [~/.aws/credentials] # コマンドの実行結果が返されることを確認 $ aws --profile reshine-assume s3 ls 2023-04-06 05:17:42 log-private-reshine-jp 2023-04-06 05:24:28 management-log-private-reshine-jp 2023-04-07 05:12:11 private-reshine-jp ... CLI - aws-assume-role (トークンの発行) 56

Slide 57

Slide 57 text

VPC 57 ● 仮想ネットワークを提供するサービス ● メタップスでは1プロダクト1AWSアカウントを原則とし、アプリケーションの環境単位で VPCを分離する運用となります ● マネジメントレイヤーからアプリケーションレイヤーへの接続は VPCペアリングで許可されていますが、アプリケーションレイヤー間の通信は許可していません ● 各種マネージドサービスは、本番環境を 2AZ、ステージング環境を1AZ構成とします VPCレイヤー VPC名用途 CIDR マネジメント management genovaやMetabaseなどの管理系インスタンス 172.30.0.0/16 アプリケーション staging ステージング環境 (Fargate、RDS、ElastiCacheなどを配置) 172.28.0.0/16 production 本番環境 172.27.0.0/16

Slide 58

Slide 58 text

VPC 58 ● 各VPCにはpublicサブネット、privateサブネットがあります。原則的にpublicサブネットにはELBのみ、その他サービスは全てprivateサブネット配置となります (Faragate、RDS、Lambdaなど) ● 各VPCにはNAT Gatewayを配置しています。AWSからインターネットに通信する際のソースIPアドレスにはEIP (固定IP) が割り当てられます

Slide 59

Slide 59 text

● AWSを操作する上で必要なアクセス権限を管理するサービス ● 開発者のロールに合わせて最小限のポリシーを付与しています ● 開発マネジャー ○ Administrator相当の権限を付与します。ただしインフラ構成は IaCで管理しているため、原則的にリソースの変更依頼は SRE に依頼してください (技術検証時における一時的な変更は問題ありません ) ○ Administratorは強力な権限を持つため、ロール付与対象は原則開発マネジャー限定します。リードエンジニア相当のメンバーに権限を付与する必要がある場合は担当 SREに相談してください ● 開発者 ○ 操作可能な環境やリソースは限定されます。 ● AWS内のマシン (EC2インスタンスやLambda関数など) ○ AWSサービス間の認証には IAMロールを使います。個人に発行しているアクセスキーはアプリケーションコードに埋め込まないよう注意してください ○ IAMロールに必要な最小限のポリシーを担当 SREに共有してください ● アクセスキー、シークレットアクセスキーは共有禁止です ○ AWSに限らず、アカウントの共有は例外を除いて禁止です IAM 59

Slide 60

Slide 60 text

● Q: パスワードを登録したのにAWSコンソールにログインできません ● パスワードポリシーを満たしてください ○ 最小文字数: 8文字 ○ 1文字以上のアルファベット大文字 ○ 1文字以上のアルファベット小文字 ○ 1文字以上の数字 ○ 1文字以上の記号 ● Q: ログインはできたけど、全てのページで権限がないとエラーが出ます ○ 初めに MFAの登録を行ってください IAM 60

Slide 61

Slide 61 text

● ユーザー認証基盤を提供するサービス ○ 同等のサービスには Firebase、Auth0があります ● 各プロダクトのステージング環境 (及びmetabase、genovaコンソール) Cognito認証でメンバーのアクセスを制限を行っています Cognito 61

Slide 62

Slide 62 text

● サーバーの負荷を分散するサービス ● ELB自身もトラフィックに応じてスケールしますが、5分間で50%以上のトラフィック増加が発生した場合、スケールが間に合わずHTTP 503が返される可能性があります ● キャンペーンなどでスパイクアクセス (通常時の5倍以上のリクエスト) が見込まれる場合、AWSへの暖気申請が必要となります。できる限り早めに担当SREへの共有をお願いします ELB 62

Slide 63

Slide 63 text

● S3に格納されているログに対してクエリを実行できるサービス ○ アプリケーションログや、 ELB・WAFなどのアクセスログを調査するときに役立ちます ● クエリを実行するには事前にデータベースとテーブルの作成が必要です。スキーマを共有いただければSRE側でテーブルの作成を行います Athena 63

Slide 64

Slide 64 text

● 静的コンテンツなどをCDN (Contents Delivery Network) 経由で高速配信するサービス ● ELBの手前にはCloudFrontが配置されています ○ 各プロダクトの最新の対応状況は担当 SREに確認してください ○ フロントエンドをFargateから配信しているアプリケーションの場合、アセット (CSS、JavaScript、画像など) をキャッシュ配信することが可能です ● AWSのリージョン障害や、Fargateでコンテナが起動しない場合 (バックエンドから HTTP 502、503が返された場合) はCloudFrontが自動的にカスタムメンテナンスページを表示します CloudFront 64

Slide 65

Slide 65 text

CloudFront 65

Slide 66

Slide 66 text

CloudFront 66

Slide 67

Slide 67 text

● 仮想サーバーを構築するサービス ○ メタップスのプロダクトは Fargateで稼働しているため、現在は管理用インスタンス (management-console)、開発検証用インスタンスを除いてほぼ利用していません ● Q: インスタンスに接続するには? ○ セキュリティの観点から SSHポートは開放していません。 Session Managerを利用して接続してください ■ インスタンスに接続する ● Q: EBSのバックアップ体制は? ○ 日単位で7世代 (デフォルト) 管理しています EC2 67

Slide 68

Slide 68 text

● Q: 開発検証用インスタンスがほしい ○ 起動テンプレートから EC2インスタンスを起動させてください ■ インスタンスの起動は開発マネジャー (あるいはSRE) に依頼が必要です ■ インスタンスからはRDSやElastiCacheに接続することができます ■ セキュリティポリシー上、 EC2インスタンスからFargateに接続することはできません。Fargate に接続するにはawsコマンドを利用してください ○ 作業用インスタンスはコスト削減のため、デフォルトではスポットインスタンスで起動します。インスタンスはスポット容量の不足や、入札価格次第でインスタンス終了する可能性があります。オンデマンドで常にインスタンスを起動させておきたい場合は担当 SREにご連絡ください EC2 68

Slide 69

Slide 69 text

ECS 69 ● スケーラブルかつフルマネージドなDockerコンテナの実行環境を提供するサービス ● ECSには、ECS on EC2とFargateがありますが、社内プロダクトは全てFargate、デプロイ方式はローリングデプロイで統一しています ● サーバーの負荷に応じてオートスケールする仕組みを導入しています ● アプリケーションからSTDOUTに出力されるログはDatadog Log、S3に配送されます ○ 利便性の観点から通常は Datadog Logの利用を推奨します

Slide 70

Slide 70 text

● ECSはSIGTERMプロセスをコンテナに送信し、30秒経っても終了しない場合に SIGKILLが送信されます ○ アプリケーションはSIGTERMを適切にハンドリングし、安全にアプリケーションを終了する実装が必要です ○ ECS のアプリケーションを正常にシャットダウンする方法 ECS 70

Slide 71

Slide 71 text

● スケジュールタスクの実態はEventBridgeです。分散型クラウドという仕組み上、タスクは多重実行される可能性がある点に注意してください。冪等性の保証はアプリケーションのコードレベルで保証する必要があります ○ 1 つのイベントに応じてルールが複数回トリガーされました。 CloudWatch Events で、ルールのトリガーまたはターゲットへのイベントの提供で何が保証されますか。 ○ 「後勝ちルール」、あるいは排他制御などの仕組みが必要です ○ 排他制御には一般的に RDSやElastiCache、DynamoDBなどが使われます ECS 71

Slide 72

Slide 72 text

● アプリケーションからコンテナ内のルートファイルシステムへの書き込みは禁止です ○ [ECS.5] ECS コンテナは、ルートファイルシステムへの読み取り専用アクセスに制限する必要があります。 ○ タスク定義にreadonlyRootFilesystem: trueパラメータを追加することでコンテナへの書き込みを禁止することが可能です ● アップロードされた画像のリサイズなどで一時的なファイル作成が必要なケースでは、tempfileやS3などの外部ストレージの利用を検討してください ECS 72

Slide 73

Slide 73 text

ECS ● Q: コンテナに接続するには? ○ サービスのコンテナに接続する ○ Fargate接続クライアントツールもあります ■ https://github.com/metaps/connect_to_fargate ● Q: タスク定義ファイルの作成方法が分からない ○ ベースとなるタスク定義は担当 SREが作成します ○ タスクパラメータの詳細は、タスク定義のベストプラクティスを参照してください 73

Slide 74

Slide 74 text

ECS - genova 74 ● デプロイにはgenovaを利用します ○ https://github.com/metaps/genova ● Q: どのようなデプロイ形式をサポートしますか? ○ CLI、Slack、GitHub Actionsによるデプロイ ○ サービス、スケジュールタスク、スタンドアロンタスクの実行をサポート ○ ECS on EC2、Fargateに対応 ● genovaはOSSです。使い方の質問はSlack、機能要望はIssueにお願いします。もちろんPRも大歓迎です!

Slide 75

Slide 75 text

ECS - genova (CLI) 75 ● 開発マネジャーはCLIからアプリケーションをデプロイすることが可能です ○ https://github.com/metaps/genova/wiki/CLI-deploy

Slide 76

Slide 76 text

ECS - genova (Slack) ● Slackからdeployコマンドを打つことで、Bot経由のインタラクティブなデプロイを始めることができます ● 直前に実行したデプロイを再実行するには、 redeployコマンド、履歴から再デプロイするには historyコマンドを使うと便利です 76

Slide 77

Slide 77 text

● genovaはデプロイに使用したコミットIDからタグを作成するため、再デプロイ時はタグを指定したリリースも可能です ECS - genova (Slack) 77

Slide 78

Slide 78 text

● システムがスケールするにつれて、デプロイサイクルも複雑化します。genovaはサービスやスケジュールタスクをステップ実行する仕組みを提供するため、デプロイの自動化が可能です ○ ステージング環境へのデプロイ : GitHub Actions (推奨) ■ デプロイをトリガーとするブランチとデプロイステップを定義しておくことで、コードがプッシュされたタイミングでデプロイを自動実行する ○ 本番環境へのデプロイ : genova Workflow (推奨) ■ ワークフローにデプロイステップを定義しておき、デプロイ時にワークフローを指定する形でデプロイを実行する ● リリース時に複数サービスのデプロイや、スタンドアロンタスクを実行するプロダクトにおいては、デプロイの自動化を強く推奨します ECS - genova (自動化) 78

Slide 79

Slide 79 text

● workflowの定義例 ECS - genova (自動化) 79 workflows: # バックエンドを更新後にフロントエンドサービスをリリース - name: production_release steps: - repository: backend branch: main cluster: production-app type: service resources: - backend - repository: backend branch: main cluster: production-app type: service resources: - frontend

Slide 80

Slide 80 text

ECS - genova ● 稼働中のタスクのリビジョンをAWSコンソールからロールバックする操作は非推奨です。再リリース時はタグを用いたデプロイを検討してください ● デフォルトでは、Slackのデプロイチャンネルに参加している全メンバーがデプロイ可能です ○ デプロイパーミッションを設定することで、 Slackユーザー単位でデプロイ可能なリソースを制限することが可能です ■ https://github.com/metaps/genova/wiki/Integrate-Slack 80

Slide 81

Slide 81 text

ECS - genova 81 ● Webコンソールを提供します ○ 過去のデプロイ履歴・ログの確認 ○ クラスターごとの最終デプロイステータスの確認 ○ ワークフロー定義の確認

Slide 82

Slide 82 text

● アプリケーションの設定データを管理するストレージサービス ○ 秘匿値を扱うこともできるため、データベースの接続情報や APIのアクセストークンなども管理対象となります ● アプリケーションに関わるパラメータ管理は開発ユニット、インフラに関わるパラメータ管理はSREユニット管理となります ○ パラメータストアへのキーの追加 ○ アプリケーションキーの管理も担当 SREにご連絡いただければ対応可能です Parameter Store 82

Slide 83

Slide 83 text

レイヤー命名規則担当パラメータの管理インフラ (環境に依存しない) /{APP_NAME}/general/infrastructures/foo-bar/baz SRE Terraform インフラ (環境に依存する) /{APP_NAME}/{ENV}/infrastructures/foo-bar/baz SRE Terraform アプリケーション /{APP_NAME}/{ENV}/applications/foo-bar/baz 開発マネジャー (SRE) CLI (Terraform管理対象外) Parameter Store 83

Slide 84

Slide 84 text

● フルマネージドのメール送信サービス ● SES経由で大量のメールを送信する場合、クォーター制限に引っかかる可能性があります。目安としては1日辺り5万件以上です。5万件以上のメールを送信する可能性がある場合は事前にご連絡ください ● 送信したメールがバウンスや苦情扱いされた場合、AWSが提供するサプレッションリストに登録されます。サプレッションリストに登録されたメールアドレスには以後メールが配送されません ○ サプレッションリストの登録状況確認やリストからの解除は担当 SREにご連絡ください ● SREから送信した全てのメールはS3に保管しています SES 84

Slide 85

Slide 85 text

● メールを受信したユーザーが「迷惑メール報告」を行うと、SESの苦情率が上昇します ● 苦情率は0.1%未満を維持してください。苦情率が0.5%を超える場合、メール送信が一時的に停止される可能性があります ○ 苦情率のメトリクスは AWSコンソールから確認することがでるほか、SREユニットにて監視しています ● 苦情扱いされたメールはS3に保管しています SES - 苦情率 85

Slide 86

Slide 86 text

● 存在しないメールアドレスにメールを送信するとSESのバウンス率が上昇します ● バウンス率は2%未満を維持してください。10%を超える場合、メール送信が一時的に停止される可能性があります ○ SREユニットでは苦情率同様にバウンス率を監視しています ● バウンス扱いされたメールはS3に保管しています SES - バウンス率 86

Slide 87

Slide 87 text

● フルマネージド型のリレーショナルデータベースサービス ● メタップスでは標準データベースとしてAurora MySQL 2 (または3) を採用しています。順次各プロダクトのアップグレードを実施していますが、優先希望があればご連絡ください ● アプリケーションからRDSに接続する際のエンドポイント名は、クラスター名ではなく、サービスディスカバリで割り当てられた名前を指定してください ○ 例: db-writer.re-shine.internal ● データベースの負荷軽減のため、書き込みはプライマリ、参照クエリはレプリカの使用を検討してください RDS 87

Slide 88

Slide 88 text

● データベースへの接続にはコネクションプーリングを検討してください ○ 適切なプーリングサイズの設計は担当 SREに相談してください ■ Aurora MySQL DB インスタンスへの最大接続数 ● ステートレスなアプリケーション (Lambdaなど) からRDSに接続する際はコネクションが保持されない点に注意してください。コネクションプール可能なRDS Proxyの導入を検討しましょう ● アプリケーションとRDSとの接続はデフォルトでSSL通信が無効です。通信の暗号化を推奨します ● SSL/TLS を使用した DB クラスターへの接続の暗号化 RDS 88

Slide 89

Slide 89 text

● Q: バックアップ体制は? ○ 日単位で7世代 (デフォルト) 管理しています ● Q: データベースに秘匿性の高いデータを保存するには? ○ パスワードはハッシュ化、複合が必要なデータは KMSの利用を検討してください ● Q: EC2やFargateからmysqlコマンドでデータベースに接続したい ○ mysqlコマンドでデータベースに接続する ● Q: ローカル環境からRDSに接続するには? ○ SSMとInstance Connectを用いたMySQLへの接続 RDS 89

Slide 90

Slide 90 text

● バックアップ方法には、mysqldumpなどのコマンドベースのバックアップと、RDSのスナップショット機能を用いたバックアップがあります。用途に合わせて使い分けてください RDS 90 コマンドベーススナップショットデータベースへの負荷高低バックアップ速度実行環境による AWSインフラストラクチャで実行安全性実行環境による高バックアップ対象データベースデータベースを含むインフラストラクチャレベル復旧速度速い遅い (クラスターを構築するため、数十分以上の時間を要する) 開発者による実行可能 (プロダクトの運用ポリシーによる) 不可能 (開発マネジャー、SREのみ)

Slide 91

Slide 91 text

● スローログを確認するには、CloudWatch Logs Insightsを利用してください ○ AWSコンソールからCloudWatch Logsを開き、[ログのインサイト] を選択 ○ [ロググループを選択 ] にスローログのロググループを指定 ■ 例: /aws/cluster/production/slowquery ○ [クエリの実行] を押下 ● 遅いクエリを検出したらクエリの実行計画 (EXPLAIN) を確認し、クエリのチューニングやインデックスの付け替えを検討してください RDS 91

Slide 92

Slide 92 text

● フルマネージドのメモリキャッシュサービス ○ 社内プロダクトはRedisを採用しています。セッションやコンテンツの一次キャッシュ領域として利用を検討してください ● 社内プロダクトのバージョンは6.xです。7.xへのアップグレードは順次実施していますが、優先対応を希望の場合は担当SREに相談してください ● アプリケーションからElastiCacheに接続する際のエンドポイント名は、クラスター名ではなく、サービスディスカバリで割り当てられた名前を指定してください ○ 例: cache-writer.re-shine.internal ● RDS同様、レプリカの参照とコネクションプーリングの導入を検討してください ElastiCache 92

Slide 93

Slide 93 text

● ElastiCacheを非クラスターモードで使用する場合 (デフォルト)、データベース番号として0〜15の計16データベースを扱うことができます。用途に合わせて使用するデータベース番号を設計してください ● キャッシュキーには有効期限 (TTL) をつけてください。メモリが溢れるとEvictionにより、有効期限の設定された古いキーから順に削除が行われます。キーが削除できない場合はメモリが溢れ、書き込みエラーが発生します ○ SREユニットではRedisのEvictionやメモリ使用率を監視しています ElastiCache 93

Slide 94

Slide 94 text

● オブジェクトストレージサービス ○ アプリケーションから配信するアセットは S3からの配信を検討してください ● 認証されたユーザーにのみオブジェクトを返却したい場合は、署名付きURL (Pre-Signed URL) を利用してください ○ 一覧画面などで署名付き URLのリストを表示すると、レスポンスまでに時間がかかる可能性があります。CloudFrontの署名付きURL発行や、フロントエンドの遅延ローディング (Lazy Loading) 実装を検討してください ● 恒久的に残す必要のないファイル (ログ、一時ファイルなど) はセキュリティの観点からも定期的に削除することを推奨します ○ S3のライフサイクルルールを使うことで不要なオブジェクトの定期的な削除が可能です S3 94

Slide 95

Slide 95 text

● フロントエンドアプリケーション配信サービス ○ Route 53 + CloudFront + S3を組み合わせた機能を提供します ● Amplifyでは環境変数を扱うことができますが、秘匿値は環境変数に含めるべきではありません。環境シークレットの利用を検討してください ○ 環境シークレットを設定 ● コンテンツ配信を最適化するためのパフォーマンスモード機能があります ○ パフォーマンスモードを有効化することで、コンテンツが CloudFrontから配信されます ○ カスタムヘッダーを利用することで、特定のパス以下のみキャッシュ制御が可能です Amplify 95

Slide 96

Slide 96 text

● APIの公開や管理を提供するマネージド型サービス ○ NLBやLambdaとのインテグレーションが可能 ● API Gatewayの接続タイムアウトの最大時間は29秒です。AWS側の制約により上限申請はできません ○ リクエストがタイムアウトした場合であっても、バックエンドにフォワードされたリクエストは中断されない点に注意してください。処理に時間のかかるアプリケーションロジックはメッセージキューの導入を検討してください API Gateway 96

Slide 97

Slide 97 text

● マネージド型のJSONドキュメントデータベース (MongoDB互換) ● SRE:shineにおいて、SaaS/PaaSから収集したイベントログを保管するデータベースとして使用しています ● 変更ストリーム機能を用いて、コレクション内で発生した変更イベントをAWSの他のサービス (RedshiftやOpenSearch Service) に通知することが可能です ○ DocumentDBは日本語の全文検索に対応していないため、 SRE:shineでは将来的にOpenSearch Serviceとの連携を検討しています DocumentDB 97

Slide 98

Slide 98 text

Lambda 98 ● サーバーレスなアプリケーション基盤サービス ○ 社内ではメタップスクラウド、 SRE:shineなどで利用中です。アプリケーション開発には Serverless Fameworkを採用しています ● アプリケーションのパフォーマンスを監視するため、Datadog APMのセットアップを推奨します ○ APMのセットアップ方法には Datadog Forwarder、Lambda Extensionの2パターンがあります。推奨はLambda Extension方式ですが、詳しくは担当 SREとご相談ください ● Pythonのランタイムpython 3.7が2023年11月27日に廃止されるため、 python3.8以上への移行が必要です ● GoのランタイムGo 1.xが2023年12月31日に廃止されるため、provided.al2への移行が必要です

Slide 99

Slide 99 text

SQS 99 ● マネージド型メッセージキューサービス ○ SQSを導入することで、メッセージの送信と受信側の処理を非同期化することができます ● Railsには同等のサービスとしてSidekiqがありますが、SREユニットではAWSを使う上でSQSの利用を推奨しています ○ SidekiqをECSで利用する場合、タスクの停止で実行中のジョブが消失してしまう ○ SQSはDatadogでキューの状態を監視可能 ■ Sidekiqは上位プランへのアップグレードが必要 ○ SQS (EventBridge) をトリガーにLambdaやFargateを起動することができる

Slide 100

Slide 100 text

● データ検索に特化した全文検索エンジンサービス ○ re:shineにおいてはユーザーやプロジェクトのレコメンド機能として利用 ● OpenSearch Serviceを利用する課題として、フルマネージドではあるものの、 AWSが推奨する最小構成はそれなりにコストが高く、コストを抑えようとすると動作が不安定となる問題があります OpenSearch Service 100

Slide 101

Slide 101 text

● WebアプリケーションをXSSやSQLインジェクションといった一般的な攻撃から保護するサービス ● DDoS対策に加え、Fortinet社のマネージドルールセットを契約しています (一部プロダクトを除く) ○ Cloud WAF Comparison Using Real-World Attacks ● WAFがリクエストをブロックした場合は、クライアントにHTTP 403を返します ● WAFはごく稀に誤判定を起こす可能性があります ○ 例: HTMLタグやSQLをPOSTするフォームなど ○ 特定のリクエストパスをWAFから除外することが可能です ● 脆弱性試験を実施する際は一時的にルールを除外する必要があります WAF / Shield 101

Slide 102

Slide 102 text

● サーバーレスアプリケーションを検索・デプロイ・公開するサービス ● SREユニットではトイルの削減をはじめ、インフラの運用を自動化・効率化するための環境作りをLambdaで開発しています ○ データベースのDDL更新差分の通知 ○ EC2インスタンスのセキュリティアップデート ○ SESサプレッションリスト追加の通知など Serverless Application Repository 102

Slide 103

Slide 103 text

● 開発したアプリケーションはServerless Application RepositoryからFireworkというパッケージで各AWSアカウントに配布しています。機能要望お待ちしています! Serverless Application Repository 103

Slide 104

Slide 104 text

Datadog 104 Getting Started with Datadog

Slide 105

Slide 105 text

● Q: アプリケーションログはどのようにDatadog Logに転送されますか? ○ 標準出力に吐かれたログを FireLens (FluentBit) がログクラスター (Fluentd) に送信。各サービスから収集したログを整形後、 Datadog LogsやS3に転送します ○ 標準出力のフォーマットは JSONを推奨します。アプリケーションのログ送信周りは SREユニットにて実装 (あるいは開発ユニットに依頼 ) する形となります Log 105

Slide 106

Slide 106 text

● Q: 古いログにアクセスできません ○ Datadog Logには標準で15日間のログを保管しています。より古いログを確認したい場合は S3 (Athena) から検索を行ってください Log 106

Slide 107

Slide 107 text

Log 107

Slide 108

Slide 108 text

● 全てのサービス (≒ コンテナ) にDD_ENV環境変数、一意のタグを発行しています ● サイドバーからEnv、serviceを指定することで、対象となる環境・サービスを絞り込むことができます Log 108 # ECSのタスク定義 - name: rails environment: - name: DD_ENV value: production log_configuration: log_driver: awsfirelens options: Tag: ecs-docker.backend-rails

Slide 109

Slide 109 text

● Q: ログの一覧に任意の列を追加するには? ○ ログ詳細から追加したい列名を選択して、 [Add column for ...] を指定 Log 109

Slide 110

Slide 110 text

● Q: 任意のパラメータに一致するログを抽出したい ○ ログ詳細から検索したいフィールド名を選択して、 [Filter by ...] を指定 Log 110

Slide 111

Slide 111 text

● Q: フィールド値でパターン一致するには? ○ ダブルクォートを外します Log 111

Slide 112

Slide 112 text

● Q: (JSONではなく) 文字列で送信されたメッセージを検索するには? ○ @logパラメータに入ります。スペースを表現するには、ワイルドカード "?" を使います ■ https://docs.datadoghq.com/ja/logs/explorer/search_syntax/ Log 112

Slide 113

Slide 113 text

APM 113

Slide 114

Slide 114 text

APM 114

Slide 115

Slide 115 text

APM 115

Slide 116

Slide 116 text

APM 116

Slide 117

Slide 117 text

セキュリティ 117 Security

Slide 118

Slide 118 text

セキュリティの責任分界点 118

Slide 119

Slide 119 text

セキュリティの責任分界点保護対象開発ユニット SREユニットデータの保護 ◯ 秘匿値の管理 ◯ 通信の暗号化・ストレージの暗号化アプリケーションコード ◯ ☓ 静的解析ツールの導入を検討中アプリケーションのパッケージ管理 ◯ EOSLの管理 ◯ 脆弱性の自動検知・修復の仕組みを提供 Dockerイメージ ◯ ◯ イメージに対するセキュリティパッチ適用 OS ☓ ◯ IPS / IDSの運用 ☓ ◯ 119

Slide 120

Slide 120 text

● AWSが提供する各種セキュリティサービス (Inspector、Config、SecuirtyHub、 GuardDutyなど) を有効化し、SRE:shineにイベントログを収集。全てのプロダクトを横断する形でダッシュボードによる可視化を進めていますセキュリティ異常を検知する仕組み 120

Slide 121

Slide 121 text

● GitHubのDependabotを使うことで、アプリケーションが利用しているライブラリ (Gemfileやgo.modなど) の脆弱性を検知し、対策となるPRを自動作成することができます ○ DependabotはSREが管理する全てのリポジトリで有効化しています ● 管理するリポジトリが多いと、ライブラリのアップデート頻度によってはPR確認、マージのコストが高くなります。SREユニットではこの問題を解決するためのアクション action-dependabot-auto-merge を開発しました ○ Dependabotが提案したPRを自動でマージすることができます。既にメタップスクラウドでは運用に導入済みとなり、今後他のプロダクトにも展開します (導入は必須ではなく任意です ) Dependabot 121

Slide 122

Slide 122 text

最後に 122 Closing Remarks

Slide 123

Slide 123 text

2023年のロードマップ ● AWSコストの異常検知 ○ MLベースでコスト異常のアラート通知を導入します ● AWS Graviton (ARM)プロセッサへの移行 ○ 何が嬉しいか ■ パフォーマンスの向上とコスト削減 ○ RDSやElastiCacheといったフルマネージドサービスを順次Gravitonベースに移行 ○ FargateのARM化も検証を開始しました ● アプリケーションコードセキュリティ ○ 継続的なコード品質・コードセキュリティチェックの基盤として SonarCubeの導入 (GitHubとの統合) を予定しています ● SRE:shineとの統合 ○ AWSやDatadog、SentryなどのイベントデータをSRE:shineに集約することで、障害発生時の一時レスポンス対応が迅速になります ○ 各プロダクトの脆弱性情報が集約されるため、アプリケーションごとのセキュリティリスク分析・パッチ適用が容易になります 123

Slide 124

Slide 124 text

インフラに関して分からないことがあればSREユニットにご相談ください! 124