Deep dive into cloud design

Transcript

1. Deep dive into cloud design White paper version 1
2. • 本資料はメタップスの開発者向けに、開発者自身が関わるプロダクトのインフラ構 成や、クラウド設計の理解を深めるための資料となります • 資料のボリュームが大きいため、勉強会の場では重要な箇所をピックアップして解 説します ◦ ログの調査方法やコードスニペットも含まれるため、資料自体をブックマークしておくことをお勧めし ます。資料の内容は随時アップデートします。 はじめに 2
3. SREはSite Reliability Engineeringの略称です 3
4. ? 4
5. https://cloud.google.com/sre 5
6. 6 SRE は、信頼性の高い本番環境システムを実行するための職務、 マインドセット、エンジニアリング手法のセットです。 Google Cloud では、ツールやプロフェッショナル サービスなどのリ ソースを通じて、SRE の原則を実装できるよう支援しています。
7. ? 7
8. ChatGPT 8
9. SREは「Site Reliability Engineering」の略で、Googleが開発し た運用の手法です。 ソフトウェアシステムの信頼性、スケーラビリティ、効率性を確保す るための工学的手法を用いてシステムを管理・運用する役割を指し ます。 SREの目的は、サービスを持続可能な方法で高速に提供すること、 そして障害が発生した場合でも迅速に復旧できる能力を確保するこ とです。 9
10. SREユニットの紹介 10 Introduction to the SRE Unit
11. • メタップスグループにおけるインフラ運用のエキスパート ◦ インフラ基盤の設計・構築をはじめ、運用の自動化、オンコール、開発支援、パフォーマンス分析、 セキュリティ施策といった様々な幅広い知識と、システムを俯瞰した視点から課題や改善点を見出 すスキルが求められる • Dev/Opsプラットフォームの開発 ◦ プロダクトを横断した組織として、共通基盤となる強固な Dev/Opsプラットフォームを構築。各社で 培ったノウハウを取り入れつつ、定常的なインフラ改善、安定した運用に取り組む SREユニットのミッション 11
12. ユニット体制 12
13. • 何をやってるのか ◦ インフラ設計・運用・構成アップグレード ◦ クラウド基盤へのアプリケーションの統合 ◦ CI/CDの構築 ◦ クラウドネイティブ設計のサポート ◦ トイルの削減 (運用の自動化) ◦ 監視・SLO ◦ オンコール・ポストモーテム • 各プロダクトのAWS運用は専属のEmbedded SREが担当します ユニット体制 - Embedded SREs 13
14. • 何をやってるのか ◦ DevOps基盤の構築 (IaC、CI/CD) ▪ 技術スタックの選定、基盤となるプラットフォームの開発 ◦ SRE:shineの開発 ▪ アラートを監視するダッシュボードの導入 ユニット体制 - Platform SREs 14
15. • 各プロダクトごと月に数本の機能アップデートを実施 • ベースとなるWebアプリケーション環境で安定動作が 確認された機能順次横展開しています インフラ構成のアップデート 15
16. • 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発行ユーティリティ
17. SREユニットが提供する技術スタック 17 Technology Stack Offered by the SRE Unit
18. インフラ基盤の基本構成 18 • SREチームが提供する社内共通基盤は次の通りです ◦ GitHub ◦ AWS ◦ Datadog ◦ Sentry ◦ PagerDuty • 各事業体で独自に採用しているSaaS/PaaSもありますが、原則的にはSREチーム でアカウントを管理し、可能な限りIaCベースでインフラを構築しています ◦ Deep Security ◦ GCP ◦ SendGrid ◦ Firebase など
19. 権限の移譲 • 各事業体の開発マネジャーにはSaaS/PaaSのフルアクセス権限を付与しています が、原則的にSREユニットが管理する基盤の設定変更は担当SREに依頼してくだ さい ◦ SREユニットではリソースの状態管理を統一するべく、 IaCをベースにコード管理しています ◦ 一時的な検証における設定変更は問題ありません ◦ 急ぎの作業などでマネジャー側で設定を変更した場合は変更内容を担当 SREに共有してください。 変更内容が共有されていない場合、コードの上書きによって設定がロールバックされる恐れがあり ます 19
20. • リポジトリの作成・ユーザーの追加、削除など ◦ 担当SREに依頼してください • Code Copilot ◦ 9月頃に申請ベースで利用可能となる予定です。詳細は追って アナウンスします ◦ 利用者は 運用ガイドライン を一読してください GitHub 20
21. • Q: GitHubの通知をSlackで受け取るには? ◦ 各プロダクトのgithubチャンネルに参加することで、 GitHub上のメンションをSlackで受け取ることが できます ◦ チャンネルへの参加は開発マネジャー、あるいは担当 SREにご連絡ください GitHub 21
22. • Slack連携方法 ◦ Slackを開き、左ペインから [Apps] の右横にある [+] を選択 ◦ アプリ一覧から GitHub を検索して、表示されたアプリを選択 ◦ GitHubとの連携ボタンが表示されるので、 [Connect GitHub account] ボタンを押下 ◦ OAuthのページが開くので、 [Connect GitHub account] ボタンを押して、SlackとGitHubを連携させる • 動作確認 ◦ GitHub Issue上で自分のGitHubアカウントにメンションしたとき、 OSから通知が届けば連携が成功 しています GitHub 22
23. • CI/CD基盤にはGitHub Actionsを利用しています ◦ 1ヶ月あたりおよそ133時間のテストが走ってます (2023年7月の統計) • テストを高速化するために ◦ テストを並列実行する ▪ ジョブにマトリックスを使用する ◦ パッケージのインストールはキャッシュする ▪ 依存関係をキャッシュしてワークフローのスピードを上げる ◦ 高速なビルドツール、テストツールへの移行 ▪ Turbopack、Vitestなど ◦ テストランナーの変更 GitHub Actions 23
24. • メタップス全プロダクトの基盤となるインフラです • SREユニットでは Well-Architected に準拠した設計を目指 しています • インフラの新機能検証や導入は原則re:shine環境がベースとなっています ◦ re:shineはFTR (AWS Foundational Technical Review) を取得してます ◦ FTRとは? ▪ AWS パートナーのソフトウェアまたはソリューションがセキュリティ、信頼性、運用上の優秀 性に関連する AWS ベストプラクティスに沿っていることを確認し、リスクを特定して修正する ための技術レビューです。 ...(中略) AWS パートナーネットワークでソフトウェアパスに参加し て FTR を通過したソフトウェアまたはソリューションは、「 AWS 認定ソフトウェア (AWS Qualified Software)」として正式に認められます AWS 24
25. Datadog • アプリケーション・インフラの監視サービス • 主に次のサービスを利用しています。開発メンバーはLog、APMの使い方を習得し てください (後述) ◦ Monitor ▪ メトリクスのしきい値を監視し、異常が検知された場合は Slackに通知。重要度の高いアラー トはPagerDutyにエスカレーション (本番環境のみ) ◦ Synthetic ▪ HTTPやgRPCによるWebアプリケーションの外形監視 (本番環境のみ) ◦ Log ▪ アプリケーションログの収集と検索を提供 ◦ APM ▪ アプリケーションのパフォーマンスを分析 25
26. • アプリケーションのエラートラッキングツールです。アプリケーション発生した例外を Sentryでキャプチャすることで、例外ごとの発生頻度やエラーの詳細をSentryの ダッシュボードで確認することができます • 例外が発生した際は、各プロダクトのSlack チャンネルにアラートを通知する仕組みを 導入しています ◦ チャンネル名: {プロダクト名}-sentry • Sentryのアラートは現在のところオンコール対象外です。 各プロダクトの開発マネジャーは、チーム内でアラートを監視する体制を構築する 必要があります Sentry 26
27. Sentry 27
28. • インシデント管理ツールです。DatadogやSentryなどのSaaSからエスカレーションされた 障害をオンコール担当者に通知することができます • SREユニットではメンバー全員がオンコールに 参加しており、社内外のインフラを24/365体制 で監視しています • 代表的なオンコール対象メトリクスの例 ◦ アプリケーションがHTTP 5xxを返した ◦ 外形監視が失敗 ◦ ヘルスチェックが失敗 • オンコールとしないメトリクスの例 ◦ ネットワークレイテンシーの上昇 ◦ CPU、メモリなどのリソース使用率上昇 PagerDuty 28
29. PagerDuty 29
30. • データベースを可視化するBIツールです。GUIベース、あるいはネイティブクエリで ダッシュボードを作成することができます • Metabaseからは本番のデータベース (レプリカ) を参照します。負荷対策のため ビューは一定時間キャッシュされます ◦ 最新のデータを取得したい場合はクエリベースでデータを取得してください Metabase 30
31. Metabase 31
32. • VPNが必要な開発者にはOpenVPNのアカウントを発行しています OpenVPN 32
33. • IPS (不正侵入防御)、IDS (不正侵入検知) の役割として、一部のプロダクトではト レンドマイクロ社のCloud Oneを導入しています • Cloud One Workload Securityを導入することで、不正プロ グラム対策 (マルウェア) や不正な通信をネットワークレベル で遮断することが可能となります ◦ Workload SecurityはAmazon EC2を保護します。サーバーレス環境 (FargateやLambdaなど) はサポート対象外となります Cloud One Workload Security 33
34. Cloud One Workload Security 34
35. インフラ基盤の基本構成 35
36. アプリケーション設計 36 Application design
37. • モダンなWebアプリケーションのあるべき姿を12のベストプラクティスにまとめた方 法論。必読です ◦ https://12factor.net/ja/ • Beyond the Twelve-Factor App ◦ 2016年に発表されたTwelve Factor Appのアップデート版 THE TWELVE-FACTOR APP 37
38. THE TWELVE-FACTOR APP 38 1. コードベース バージョン管理されている 1つのコードベースと複数のデプロイ 2. 依存関係 依存関係を明示的に宣言し分離する 3. 設定 設定を環境変数に格納する 4. バックエンドサービス バックエンドサービスをアタッチされたリソースとして扱う 5. ビルド、リリース、実行 ビルド、リリース、実行の 3つのステージを厳密に分離する 6. プロセス アプリケーションを 1つもしくは複数のステートレスなプロセスとして実行 する 7. ポートバインディング ポートバインディングを通してサービスを公開する 8. 並行性 プロセスモデルによってスケールアウトする 9. 廃棄容易性 高速な起動とグレースフルシャットダウンで堅牢性を最大化する 10. 開発/本番一致 開発、ステージング、本番環境をできるだけ一致させた状態を保つ 11. ログ ログをイベントストリームとして扱う 12. 管理プロセス 管理タスクを1回限りのプロセスとして実行する
39. フロントエンド開発 • Webパフォーマンスを意識して実装を行ってください ◦ Lighthouseや PageSpeed Insights でアプリケーションのパフォーマンスを計測してください ◦ RUM (Real User Monitoring) を導入することで、UX分析やエラー分析、パフォーマンス分析が可 能となります (例: Sentry Performance Monitoring、Datadog RUMなど) • アンチパターンの例 ◦ アセットがCDNから配信されていない ◦ アセットが圧縮 (あるいはバンドル) されていない ◦ 適切な画像フォーマットやリサイズが適用されていない ◦ SPAで起こりやすい問題 ▪ 構成されたアプリケーションがリロード時に HTTP 304を返している (HTTP 200を推奨) ▪ 同一エンド ポイントに多重リクエストが実行されている ▪ APIの例外が捕捉されず、画面全体の挙動に影響が発生 39
40. • 秘匿値はソースコードに埋め込まないでください ◦ 秘匿値とは、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
41. バックエンド 41 • 通信のタイムアウト ◦ アプリケーションがELB配下で動作する場合、 アプリケーションのタイムアウトは ELBのタイムアウト に依存する点に注意 が必要してください (デフォルト60秒) ◦ CSVファイルのダウンロードなど実行に時間がかかる処理は、メッセージキューの導入を検討してく ださい ◦ アプリケーションが外部と通信する際は、接続タイムアウトを考慮してください。 通信中はアプリケー ションのスレッドが専有されることを意識しましょう • データベースアクセス ◦ デッドロック、行ロックは Datadogアラートで検知します。アラート発生時は SRE側で一次調査を行 います ◦ スローログに関しては 1秒以上かかるクエリを CloudWatch Logsに記録しています (後述) ◦ クエリのパフォーマンスは、 Datadog APMからも確認することができます (後述)
42. • 接続の再試行 (Exponential Backoff) ◦ 外部サービスと通信する際は、ネットワークや相手側のサーバーの問題で、一時的に接続が不安 定になる可能性があります。一定時間内にレスポンスがない場合は再試行する仕組みを検討して ください • アンチパターンの例 ◦ N+1 (後述しますが、Datadog APMから確認可能です) ◦ 画像アップロード機能からアップロードされたファイル名が、サーバー側でリネームされず、オリジナ ルの名前でアクセスできてしまう (例: スクリーンショット.png) ◦ 画像が圧縮・リサイズされておらず、フロントエンドで画像一覧を表示する際のパフォーマンスが低 い ◦ ファットなAPIレスポンス (モデルデータをそのまま JSONに変換) ◦ URLパラメータを書き換えることで、本来権限のないページにアクセスできてしまう バックエンド 42
43. • 常に最新のミドルウェアやパッケージを利用してください • ビルドに時間がかかる場合、ベースイメージの作成を検討してください ◦ DockerHubやECRにベースイメージを登録しておくことで、アプリケーションビルドにかかる時間を 高速化することができます # RedHad RUN yum update -y # Debian RUN apt-get update && apt-get upgrade # Alpine Linux RUN apk update && apk upgrade Dockerfile 43
44. • Q: コンテナの起動が遅い ◦ マルチステージビルドを検討してください ◦ コンテナ起動直後から ELBによるHTTPヘルスチェックが走ります。サーバーの起動に時間がかか るとヘルスチェックが失敗し、コンテナが終了する恐れがあるので注意してください ▪ コンテナ起動直後のヘルスチェック猶予期間はデフォルトで 300秒です。 Dockerfile 44
45. • IPアドレスの制限 ◦ 外部から内部への通信 ▪ 外部ベンダーからリクエストを受け付ける APIエンドポイントを提供する場合、リクエスト送信 元 (ベンダー) のIPアドレスが静的なものか確認し、 可能な限り接続元の制限を行ってくださ い ▪ IPアドレスはネットワークレベルでの遮断が望ましいため、ロードバランサー (WAF) 側での 制御を推奨とします。 IPアドレスの制限依頼は担当 SREにご連絡ください ◦ 内部から外部への通信 ▪ 接続先のベンダーによっては接続元の IPアドレスが制限される場合があります。 AWS内の サービスがインターネットに出る際の送信元 IPは固定となるため、SREから共有されたIPアド レスを案内してください バックエンド 45
46. • アプリケーションのメンテナンス ◦ アプリケーションのリリース要件や、インフラ基盤のアップグレード要件に伴い、アプリケーションをメ ンテナンスモードに切り替えるケースがあります ◦ メンテナンス期間中はクローラー対策として HTTPステータスは503を返してください。 ▪ APIエンドポイントはJSON形式でエラーを返す実装を推奨します ◦ メンテナンス切り替えはアプリケーション側で実装するか、インフラで切り替えるか、システムの特性 に合わせて検討が必要です バックエンド 46 切り替え方法 メリット デメリット インフラ (ELB) ・アプリケーションレベルでの実装が不要 ・システム全体で一貫した切り替えが可能 複雑な条件でのメンテナンス切り替えは難しい可能 性がある アプリケーション より細かいアクセス制限が可能 ・複数のサービスで構成される場合、メンテナンスデ プロイに時間がかかる ・インフラ基盤側の障害に対応できない
47. • 障害が発生した際のユーザー告知フローをあらかじめ決めておいてください ◦ 告知テンプレートの作成 ▪ 初期告知・更新告知・復旧告知 ◦ 障害発生時のエスカレーション ▪ 例: エンジニア→マネジャー→ 事業責任者による判断 → 広報・CSからの情報配信 ◦ 告知チャンネル ▪ サイト内での告知 ▪ メール配信 ▪ 社内アナウンス (Slackなど) ▪ SNS (Facebook、Xなど) 障害発生時のアナウンス (開発マネジャー) 47
48. • SREユニットではシステム障害が発生した際、事後分析としてポストモーテム会を 実施しています。事後分析の目的はインシデントを文書化した上で、根本となる原 因を理解し、再発の可能性や影響を低減することを目的とします ◦ ポストモーテム会への参加は、開発・ SREメンバー、開発マネジャー・事業責任者となります (障害 の重大度による) • SREユニットが主催するポストモーテム会のガイドライン • 過去に発生した障害、及びポストモーテムドキュメント ポストモーテム会の実施 48
49. AWSを用いたアプリケーション開発 49 Application development with AWS
50. AWSの操作方法 - コンソール • WebからログインしてAWSの全てのサービスにアクセスすることができます • リソースの操作は画面ベースで 変更可能です。 その反面、設定変更などのレビュ ーが難しい側面があります (👉👮) • 一部の操作はGUIから行うことが できません 50
51. • awsコマンドを用いてリソースを 操作します • コマンドベースの操作となるため、 変更内容をレビューしやすいメリット があります • AWSコンソールより迅速にリソースの 状態を確認すること可能です AWSの操作方法 - CLI 51 $ aws s3 ls
52. • アプリケーションからAWSのリソースを操作するにはAPIを使います • SREユニットが採用しているTerraformも内部的にはAWS APIをコールしています AWSの操作方法 - API 52 client = Aws::S3::Client.new client.list_buckets.buckets.each do |bucket| # ... end
53. • 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
54. CLI - MFAの登録 54 • IAMアカウントでAWSコン ソールにログイン後、右上のメニューから [セキュリ ティ認証情報] を開き、[多要素認証 (MFA)] から仮想 デバイス (Google Authenticatorなど) を登録してくだ さい。 発行された識別子を控えておきます • 同じページ内の [アクセスキー] から [アクセスキ ーを作成] を選択してアクセスキーを発行して ください。 クレデンシャル情報ですので扱いには注意が 必要です
55. 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
56. # 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
57. 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
58. VPC 58 • 各VPCにはpublicサブネット、privateサブネットがあります。原則的にpublicサブ ネットにはELBのみ、その他サービスは全てprivateサブネット配置となります (Faragate、RDS、Lambdaなど) • 各VPCにはNAT Gatewayを配置しています。AWSからインターネットに通信する 際のソースIPアドレスにはEIP (固定IP) が割り当てられます
59. • AWSを操作する上で必要なアクセス権限を管理するサービス • 開発者のロールに合わせて最小限のポリシーを付与しています • 開発マネジャー ◦ Administrator相当の権限を付与します。ただしインフラ構成は IaCで管理しているため、原則的にリソースの変更依頼は SRE に依頼してください (技術検証時における一時的な変更は問題ありません ) ◦ Administratorは強力な権限を持つため、ロール付与対象は原則開発マネジャー限定します。 リードエンジニア相当のメン バーに権限を付与する必要がある場合は担当 SREに相談してください • 開発者 ◦ 操作可能な環境やリソースは限定されます。 • AWS内のマシン (EC2インスタンスやLambda関数など) ◦ AWSサービス間の認証には IAMロールを使います。 個人に発行しているアクセスキーはアプリケーションコードに埋め込まな いよう注意してください ◦ IAMロールに必要な最小限のポリシーを担当 SREに共有してください • アクセスキー、シークレットアクセスキーは共有禁止です ◦ AWSに限らず、アカウントの共有は例外を除いて禁止です IAM 59
60. • Q: パスワードを登録したのにAWSコンソールにログインできません • パスワードポリシーを満たしてください ◦ 最小文字数: 8文字 ◦ 1文字以上のアルファベット大文字 ◦ 1文字以上のアルファベット小文字 ◦ 1文字以上の数字 ◦ 1文字以上の記号 • Q: ログインはできたけど、全てのページで権限がないとエラーが出ます ◦ 初めに MFAの登録 を行ってください IAM 60
61. • ユーザー認証基盤を提供するサービス ◦ 同等のサービスには Firebase、Auth0があります • 各プロダクトのステージング環境 (及びmetabase、genovaコンソール) Cognito認 証でメンバーのアクセスを制限を行っています Cognito 61
62. • サーバーの負荷を分散するサービス • ELB自身もトラフィックに応じてスケールしますが、5分間で50%以上のトラフィック 増加が発生した場合、スケールが間に合わずHTTP 503が返される可能性があり ます • キャンペーンなどでスパイクアクセス (通常時の5倍以上のリクエスト) が見込まれ る場合、AWSへの暖気申請が必要となります。できる限り早めに担当SREへの共 有をお願いします ELB 62
63. • S3に格納されているログに対してクエリを実行できるサービス ◦ アプリケーションログや、 ELB・WAFなどのアクセスログを調査するときに役立ちます • クエリを実行するには事前にデータベースとテーブルの作成が必要です。スキーマ を共有いただければSRE側でテーブルの作成を行います Athena 63
64. • 静的コンテンツなどをCDN (Contents Delivery Network) 経由で高速配信する サービス • ELBの手前にはCloudFrontが配置されています ◦ 各プロダクトの最新の対応状況は担当 SREに確認してください ◦ フロントエンドをFargateから配信しているアプリケーションの場合、アセット (CSS、JavaScript、画 像など) をキャッシュ配信することが可能です • AWSのリージョン障害や、Fargateでコンテナが起動しない場合 (バックエンドから HTTP 502、503が返された場合) はCloudFrontが自動的にカスタムメンテナンス ページを表示します CloudFront 64
65. CloudFront 65
66. CloudFront 66
67. • 仮想サーバーを構築するサービス ◦ メタップスのプロダクトは Fargateで稼働しているため、現在は管理用インスタンス (management-console)、開発検証用インスタンスを除いてほぼ利用していません • Q: インスタンスに接続するには? ◦ セキュリティの観点から SSHポートは開放していません。 Session Managerを利用して接続してくだ さい ▪ インスタンスに接続する • Q: EBSのバックアップ体制は? ◦ 日単位で7世代 (デフォルト) 管理しています EC2 67
68. • Q: 開発検証用インスタンスがほしい ◦ 起動テンプレートから EC2インスタンスを起動させてください ▪ インスタンスの起動は開発マネジャー (あるいはSRE) に依頼が必要です ▪ インスタンスからはRDSやElastiCacheに接続することができます ▪ セキュリティポリシー上、 EC2インスタンスからFargateに接続することはできません 。Fargate に接続するにはawsコマンドを利用してください ◦ 作業用インスタンスはコスト削減のため、デフォルトでは スポットインスタンスで起動 します。インスタ ンスはスポット容量の不足や、入札価格次第でインスタンス終了する可能性があります。 オンデマ ンドで常にインスタンスを起動させておきたい場合は担当 SREにご連絡ください EC2 68
69. ECS 69 • スケーラブルかつフルマネージドなDockerコンテナの実行環境を提供するサービ ス • ECSには、ECS on EC2とFargateがありますが、社内プロダクトは全てFargate、 デプロイ方式はローリングデプロイで統一しています • サーバーの負荷に応じてオートスケールする仕組みを導入しています • アプリケーションからSTDOUTに出力されるログはDatadog Log、S3に配送されま す ◦ 利便性の観点から通常は Datadog Logの利用を推奨します
70. • ECSはSIGTERMプロセスをコンテナに送信し、30秒経っても終了しない場合に SIGKILLが送信されます ◦ アプリケーションはSIGTERMを適切にハンドリングし、安全にアプリケーションを終了する実装が必 要です ◦ ECS のアプリケーションを正常にシャットダウンする方法 ECS 70
71. • スケジュールタスクの実態はEventBridgeです。分散型クラウドという仕組み上、タ スクは多重実行される可能性がある点に注意してください。冪等性の保証はアプリ ケーションのコードレベルで保証する必要があります ◦ 1 つのイベントに応じてルールが複数回トリガーされました。 CloudWatch Events で、ルールのトリ ガーまたはターゲットへのイベントの提供で何が保証されますか。 ◦ 「後勝ちルール」、あるいは排他制御などの仕組みが必要です ◦ 排他制御には一般的に RDSやElastiCache、DynamoDBなどが使われます ECS 71
72. • アプリケーションからコンテナ内のルートファイルシステムへの書き込みは禁止です ◦ [ECS.5] ECS コンテナは、ルートファイルシステムへの読み取り専用アクセスに制限する必要があ ります。 ◦ タスク定義にreadonlyRootFilesystem: trueパラメータを追加することでコンテナへの書き込みを禁 止することが可能です • アップロードされた画像のリサイズなどで一時的なファイル作成が必要なケースで は、tempfileやS3などの外部ストレージの利用を検討してください ECS 72
73. ECS • Q: コンテナに接続するには? ◦ サービスのコンテナに接続する ◦ Fargate接続クライアントツールもあります ▪ https://github.com/metaps/connect_to_fargate • Q: タスク定義ファイルの作成方法が分からない ◦ ベースとなるタスク定義は担当 SREが作成します ◦ タスクパラメータの詳細は、 タスク定義のベストプラクティス を参照してください 73
74. ECS - genova 74 • デプロイにはgenovaを利用します ◦ https://github.com/metaps/genova • Q: どのようなデプロイ形式をサポートしますか? ◦ CLI、Slack、GitHub Actionsによるデプロイ ◦ サービス、スケジュールタスク、スタンドアロンタスクの実行をサポート ◦ ECS on EC2、Fargateに対応 • genovaはOSSです。使い方の質問はSlack、機能要望はIssueにお願いします。も ちろんPRも大歓迎です!
75. ECS - genova (CLI) 75 • 開発マネジャーはCLIからアプリケーションをデプロイすることが可能です ◦ https://github.com/metaps/genova/wiki/CLI-deploy
76. ECS - genova (Slack) • Slackからdeployコマンドを打つことで、Bot経由 のインタラクティブなデプロイを始めることが できます • 直前に実行したデプロイを再実行するには、 redeployコマンド、履歴から再デプロイするには historyコマンドを使うと便利です 76
77. • genovaはデプロイに使用したコミットIDからタグを作成するため、再デプロイ時はタ グを指定したリリースも可能です ECS - genova (Slack) 77
78. • システムがスケールするにつれて、デプロイサイクルも複雑化します。genovaは サービスやスケジュールタスクをステップ実行する仕組みを提供するため、デプロ イの自動化が可能です ◦ ステージング環境へのデプロイ : GitHub Actions (推奨) ▪ デプロイをトリガーとするブランチとデプロイステップを定義しておくことで、コードがプッシュさ れたタイミングでデプロイを自動実行する ◦ 本番環境へのデプロイ : genova Workflow (推奨) ▪ ワークフローにデプロイステップを定義しておき、デプロイ時にワークフローを指定する形でデ プロイを実行する • リリース時に複数サービスのデプロイや、スタンドアロンタスクを実行するプロダクト においては、デプロイの自動化を強く推奨します ECS - genova (自動化) 78
79. • 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
80. ECS - genova • 稼働中のタスクのリビジョンをAWSコンソールからロールバックする操作は非推奨 です。再リリース時はタグを用いたデプロイを検討してください • デフォルトでは、Slackのデプロイチャンネルに参加している全メンバーがデプロイ 可能です ◦ デプロイパーミッションを設定することで、 Slackユーザー単位でデプロイ可能なリソースを制限する ことが可能です ▪ https://github.com/metaps/genova/wiki/Integrate-Slack 80
81. ECS - genova 81 • Webコンソールを提供します ◦ 過去のデプロイ履歴・ログの確認 ◦ クラスターごとの最終デプロイステータスの確認 ◦ ワークフロー定義の確認
82. • アプリケーションの設定データを管理するストレージサービス ◦ 秘匿値を扱うこともできるため、データベースの接続情報や APIのアクセストークンなども管理対象 となります • アプリケーションに関わるパラメータ管理は開発ユニット、インフラに関わるパラメー タ管理はSREユニット管理となります ◦ パラメータストアへのキーの追加 ◦ アプリケーションキーの管理も担当 SREにご連絡いただければ対応可能です Parameter Store 82
83. レイヤー 命名規則 担当 パラメータの管理 インフラ (環境に依存しない) /{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
84. • フルマネージドのメール送信サービス • SES経由で大量のメールを送信する場合、クォーター制限に引っかかる可能性が あります。目安としては1日辺り5万件以上です。5万件以上のメールを送信する可 能性がある場合は事前にご連絡ください • 送信したメールがバウンスや苦情扱いされた場合、AWSが提供するサプレッション リストに登録されます。サプレッションリストに登録されたメールアドレスには以後 メールが配送されません ◦ サプレッションリストの登録状況確認やリストからの解除は担当 SREにご連絡ください • SREから送信した全てのメールはS3に保管しています SES 84
85. • メールを受信したユーザーが「迷惑メール報告」を行うと、SESの苦情率が上昇しま す • 苦情率は0.1%未満を維持してください。 苦情率が0.5%を超える場合、メール送信が一時的 に停止される可能性があります ◦ 苦情率のメトリクスは AWSコンソールから確認することが でるほか、SREユニットにて監視しています • 苦情扱いされたメールはS3に保管しています SES - 苦情率 85
86. • 存在しないメールアドレスにメールを送信するとSESのバウンス率が上昇します • バウンス率は2%未満を維持してください。10%を超える場合、メール送信が一時 的に停止される可能性があります ◦ SREユニットでは苦情率同様にバウンス率を監視しています • バウンス扱いされたメールはS3に保管しています SES - バウンス率 86
87. • フルマネージド型のリレーショナルデータベースサービス • メタップスでは標準データベースとしてAurora MySQL 2 (または3) を採用していま す。順次各プロダクトのアップグレードを実施していますが、優先希望があればご 連絡ください • アプリケーションからRDSに接続する際のエンドポイント名は、クラスター名ではな く、サービスディスカバリで割り当てられた名前を指定してください ◦ 例: db-writer.re-shine.internal • データベースの負荷軽減のため、書き込みはプライマリ、参照クエリはレプリカの使 用を検討してください RDS 87
88. • データベースへの接続にはコネクションプーリングを検討してください ◦ 適切なプーリングサイズの設計は担当 SREに相談してください ▪ Aurora MySQL DB インスタンスへの最大接続数 • ステートレスなアプリケーション (Lambdaなど) からRDSに接続する際はコネクショ ンが保持されない点に注意してください。コネクションプール可能なRDS Proxyの 導入を検討しましょう • アプリケーションとRDSとの接続はデフォルトでSSL通信が無効です。通信の暗号 化を推奨します • SSL/TLS を使用した DB クラスターへの接続の暗号化 RDS 88
89. • Q: バックアップ体制は? ◦ 日単位で7世代 (デフォルト) 管理しています • Q: データベースに秘匿性の高いデータを保存するには? ◦ パスワードはハッシュ化、複合が必要なデータは KMSの利用を検討してください • Q: EC2やFargateからmysqlコマンドでデータベースに接続したい ◦ mysqlコマンドでデータベースに接続する • Q: ローカル環境からRDSに接続するには? ◦ SSMとInstance Connectを用いたMySQLへの接続 RDS 89
90. • バックアップ方法には、mysqldumpなどのコマンドベースのバックアップと、RDSの スナップショット機能を用いたバックアップがあります。用途に合わせて使い分けて ください RDS 90 コマンドベース スナップショット データベースへの負荷 高 低 バックアップ速度 実行環境による AWSインフラストラクチャで実行 安全性 実行環境による 高 バックアップ対象 データベース データベースを含むインフラストラクチャレベル 復旧速度 速い 遅い (クラスターを構築するため、数十分以上 の時間を要する) 開発者による実行 可能 (プロダクトの運用ポリシーによる) 不可能 (開発マネジャー、SREのみ)
91. • スローログを確認するには、CloudWatch Logs Insightsを利用してください ◦ AWSコンソールからCloudWatch Logsを開き、[ログのインサイト] を選択 ◦ [ロググループを選択 ] にスローログのロググループを指定 ▪ 例: /aws/cluster/production/slowquery ◦ [クエリの実行] を押下 • 遅いクエリを検出したらクエリの実行 計画 (EXPLAIN) を確認し、クエリの チューニングやインデックスの付け替え を検討してください RDS 91
92. • フルマネージドのメモリキャッシュサービス ◦ 社内プロダクトはRedisを採用しています。セッションやコンテンツの一次キャッシュ領域として利用 を検討してください • 社内プロダクトのバージョンは6.xです。7.xへのアップグレードは順次実施していま すが、優先対応を希望の場合は担当SREに相談してください • アプリケーションからElastiCacheに接続する際のエンドポイント名は、クラスター名 ではなく、サービスディスカバリで割り当てられた名前を指定してください ◦ 例: cache-writer.re-shine.internal • RDS同様、レプリカの参照とコネクションプーリングの導入を検討してください ElastiCache 92
93. • ElastiCacheを非クラスターモードで使用する場合 (デフォルト)、データベース番号 として0〜15の計16データベースを扱うことができます。用途に合わせて使用する データベース番号を設計してください • キャッシュキーには有効期限 (TTL) をつけてください。メモリが溢れるとEvictionに より、有効期限の設定された古いキーから順に削除が行われます。キーが削除で きない場合はメモリが溢れ、書き込みエラーが発生します ◦ SREユニットではRedisのEvictionやメモリ使用率を監視しています ElastiCache 93
94. • オブジェクトストレージサービス ◦ アプリケーションから配信するアセットは S3からの配信を検討してください • 認証されたユーザーにのみオブジェクトを返却したい場合は、署名付きURL (Pre-Signed URL) を利用してください ◦ 一覧画面などで署名付き URLのリストを表示すると、レスポンスまでに時間がかかる可能性があり ます。CloudFrontの署名付きURL発行や、フロントエンドの遅延ローディング (Lazy Loading) 実装 を検討してください • 恒久的に残す必要のないファイル (ログ、一時ファイルなど) はセキュリティの観点 からも定期的に削除することを推奨します ◦ S3のライフサイクルルールを使うことで不要なオブジェクトの定期的な削除が可能です S3 94
95. • フロントエンドアプリケーション配信サービス ◦ Route 53 + CloudFront + S3を組み合わせた機能を提供します • Amplifyでは環境変数を扱うことができますが、秘匿値は環境変数に含めるべきで はありません。環境シークレットの利用を検討してください ◦ 環境シークレットを設定 • コンテンツ配信を最適化するためのパフォーマンスモード機能があります ◦ パフォーマンスモードを有効化することで、コンテンツが CloudFrontから配信されます ◦ カスタムヘッダーを利用することで、特定のパス以下のみキャッシュ制御が可能です Amplify 95
96. • APIの公開や管理を提供するマネージド型サービス ◦ NLBやLambdaとのインテグレーションが可能 • API Gatewayの接続タイムアウトの最大時間は29秒です。AWS側の制約により上 限申請はできません ◦ リクエストがタイムアウトした場合であっても、バックエンドにフォワードされたリクエストは中断され ない点に注意してください。処理に時間のかかるアプリケーションロジックはメッセージキューの導 入を検討してください API Gateway 96
97. • マネージド型のJSONドキュメントデータベース (MongoDB互換) • SRE:shineにおいて、SaaS/PaaSから収集したイベントログを保管するデータベー スとして使用しています • 変更ストリーム機能を用いて、コレクション内で発生した変更イベントをAWSの他の サービス (RedshiftやOpenSearch Service) に通知することが可能です ◦ DocumentDBは日本語の全文検索に対応していないため、 SRE:shineでは将来的にOpenSearch Serviceとの連携を検討しています DocumentDB 97
98. 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への 移行が必要です
99. SQS 99 • マネージド型メッセージキューサービス ◦ SQSを導入することで、メッセージの送信と受信側の処理を非同期化することができます • Railsには同等のサービスとしてSidekiqがありますが、SREユニットではAWSを使 う上でSQSの利用を推奨しています ◦ SidekiqをECSで利用する場合、タスクの停止で実行中のジョブが消失してしまう ◦ SQSはDatadogでキューの状態を監視可能 ▪ Sidekiqは上位プランへのアップグレードが必要 ◦ SQS (EventBridge) をトリガーにLambdaやFargateを起動することができる
100. • データ検索に特化した全文検索エンジンサービス ◦ re:shineにおいてはユーザーやプロジェクトのレコメンド機能として利用 • OpenSearch Serviceを利用する課題として、フルマネージドではあるものの、 AWSが推奨する最小構成はそれなりにコストが高く、コストを抑えようとすると動作 が不安定となる問題があります OpenSearch Service 100
101. • WebアプリケーションをXSSやSQLインジェクションといった一般的な攻撃から保護する サービス • DDoS対策に加え、Fortinet社のマネージドルールセットを契約しています (一部プロダクト を除く) ◦ Cloud WAF Comparison Using Real-World Attacks • WAFがリクエストをブロックした場合は、クライアントにHTTP 403を返します • WAFはごく稀に誤判定を起こす可能性があります ◦ 例: HTMLタグやSQLをPOSTするフォームなど ◦ 特定のリクエストパスをWAFから除外することが可能です • 脆弱性試験を実施する際は一時的にルールを除外する必要があります WAF / Shield 101
102. • サーバーレスアプリケーションを検索・デプロイ・公開するサービス • SREユニットではトイルの削減をはじめ、インフラの運用を自動化・効率化するため の環境作りをLambdaで開発しています ◦ データベースのDDL更新差分の通知 ◦ EC2インスタンスのセキュリティアップデート ◦ SESサプレッションリスト追加の通知 など Serverless Application Repository 102
103. • 開発したアプリケーションはServerless Application RepositoryからFireworkという パッケージで各AWSアカウントに配布しています。機能要望お待ちしています! Serverless Application Repository 103
104. Datadog 104 Getting Started with Datadog
105. • Q: アプリケーションログはどのようにDatadog Logに転送されますか? ◦ 標準出力に吐かれたログを FireLens (FluentBit) がログクラスター (Fluentd) に送信。各サービス から収集したログを整形後、 Datadog LogsやS3に転送します ◦ 標準出力のフォーマットは JSONを推奨します。アプリケーションのログ送信周りは SREユニットに て実装 (あるいは開発ユニットに依頼 ) する形となります Log 105
106. • Q: 古いログにアクセスできません ◦ Datadog Logには標準で15日間のログを保管しています。より古いログを確認したい場合は S3 (Athena) から検索を行ってください Log 106
107. Log 107
108. • 全てのサービス (≒ コンテナ) に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
109. • Q: ログの一覧に任意の列を追加するには? ◦ ログ詳細から追加したい列名を選択して、 [Add column for ...] を指定 Log 109
110. • Q: 任意のパラメータに一致するログを抽出したい ◦ ログ詳細から検索したいフィールド名を選択して、 [Filter by ...] を指定 Log 110
111. • Q: フィールド値でパターン一致するには? ◦ ダブルクォートを外します Log 111
112. • Q: (JSONではなく) 文字列で送信されたメッセージを検索するには? ◦ @logパラメータに入ります。スペースを表現するには、ワイルドカード "?" を使います ▪ https://docs.datadoghq.com/ja/logs/explorer/search_syntax/ Log 112
113. APM 113
114. APM 114
115. APM 115
116. APM 116
117. セキュリティ 117 Security
118. セキュリティの責任分界点 118
119. セキュリティの責任分界点 保護対象 開発ユニット SREユニット データの保護 ◯ 秘匿値の管理 ◯ 通信の暗号化・ストレージの暗号化 アプリケーションコード ◯ ☓ 静的解析ツールの導入を検討中 アプリケーションのパッケージ管理 ◯ EOSLの管理 ◯ 脆弱性の自動検知・修復の仕組みを提供 Dockerイメージ ◯ ◯ イメージに対するセキュリティパッチ適用 OS ☓ ◯ IPS / IDSの運用 ☓ ◯ 119
120. • AWSが提供する各種セキュリティサービス (Inspector、Config、SecuirtyHub、 GuardDutyなど) を有効化し、SRE:shineにイベントログを収集。全てのプロダクト を横断する形でダッシュボードによる可視化を進めています セキュリティ異常を検知する仕組み 120
121. • GitHubのDependabotを使うことで、アプリケーションが利用しているライブラリ (Gemfileやgo.modなど) の脆弱性を検知し、対策となるPRを自動作成することが できます ◦ DependabotはSREが管理する全てのリポジトリで有効化しています • 管理するリポジトリが多いと、ライブラリのアップデート頻度によってはPR確認、 マージのコストが高くなります。SREユニットではこの問題を解決するためのアク ション action-dependabot-auto-merge を開発しました ◦ Dependabotが提案したPRを自動でマージすることができます。既にメタップスクラウドでは運用に 導入済みとなり、今後他のプロダクトにも展開します (導入は必須ではなく任意です ) Dependabot 121
122. 最後に 122 Closing Remarks
123. 2023年のロードマップ • AWSコストの異常検知 ◦ MLベースでコスト異常のアラート通知を導入します • AWS Graviton (ARM)プロセッサへの移行 ◦ 何が嬉しいか ▪ パフォーマンスの向上とコスト削減 ◦ RDSやElastiCacheといったフルマネージドサービスを順次Gravitonベースに移行 ◦ FargateのARM化も検証を開始しました • アプリケーションコードセキュリティ ◦ 継続的なコード品質・コードセキュリティチェックの基盤として SonarCubeの導入 (GitHubとの統合) を予定しています • SRE:shineとの統合 ◦ AWSやDatadog、SentryなどのイベントデータをSRE:shineに集約することで、障害発生時の一時レスポンス対応が 迅速になります ◦ 各プロダクトの脆弱性情報が集約されるため、アプリケーションごとのセキュリティリスク分析・パッチ適用が容易にな ります 123
124. インフラに関して分からないことがあればSREユ ニットにご相談ください! 124