Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Deep dive into cloud design

Naomichi Yamakita
August 29, 2023
18

Deep dive into cloud design

Naomichi Yamakita

August 29, 2023
Tweet

Transcript

  1. ? 4

  2. ? 7

  3. • 何をやってるのか ◦ インフラ設計・運用・構成アップグレード ◦ クラウド基盤へのアプリケーションの統合 ◦ CI/CDの構築 ◦ クラウドネイティブ設計のサポート

    ◦ トイルの削減 (運用の自動化) ◦ 監視・SLO ◦ オンコール・ポストモーテム • 各プロダクトのAWS運用は専属のEmbedded SREが担当します ユニット体制 - Embedded SREs 13
  4. • 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発行ユーティリティ
  5. インフラ基盤の基本構成 18 • SREチームが提供する社内共通基盤は次の通りです ◦ GitHub ◦ AWS ◦ Datadog

    ◦ Sentry ◦ PagerDuty • 各事業体で独自に採用しているSaaS/PaaSもありますが、原則的にはSREチーム でアカウントを管理し、可能な限りIaCベースでインフラを構築しています ◦ Deep Security ◦ GCP ◦ SendGrid ◦ Firebase など
  6. • Slack連携方法 ◦ Slackを開き、左ペインから [Apps] の右横にある [+] を選択 ◦ アプリ一覧から

    GitHub を検索して、表示されたアプリを選択 ◦ GitHubとの連携ボタンが表示されるので、 [Connect GitHub account] ボタンを押下 ◦ OAuthのページが開くので、 [Connect GitHub account] ボタンを押して、SlackとGitHubを連携させる • 動作確認 ◦ GitHub Issue上で自分のGitHubアカウントにメンションしたとき、 OSから通知が届けば連携が成功 しています GitHub 22
  7. • CI/CD基盤にはGitHub Actionsを利用しています ◦ 1ヶ月あたりおよそ133時間のテストが走ってます (2023年7月の統計) • テストを高速化するために ◦ テストを並列実行する

    ▪ ジョブにマトリックスを使用する ◦ パッケージのインストールはキャッシュする ▪ 依存関係をキャッシュしてワークフローのスピードを上げる ◦ 高速なビルドツール、テストツールへの移行 ▪ Turbopack、Vitestなど ◦ テストランナーの変更 GitHub Actions 23
  8. • メタップス全プロダクトの基盤となるインフラです • SREユニットでは Well-Architected に準拠した設計を目指 しています • インフラの新機能検証や導入は原則re:shine環境がベースとなっています ◦

    re:shineはFTR (AWS Foundational Technical Review) を取得してます ◦ FTRとは? ▪ AWS パートナーのソフトウェアまたはソリューションがセキュリティ、信頼性、運用上の優秀 性に関連する AWS ベストプラクティスに沿っていることを確認し、リスクを特定して修正する ための技術レビューです。 ...(中略) AWS パートナーネットワークでソフトウェアパスに参加し て FTR を通過したソフトウェアまたはソリューションは、「 AWS 認定ソフトウェア (AWS Qualified Software)」として正式に認められます AWS 24
  9. Datadog • アプリケーション・インフラの監視サービス • 主に次のサービスを利用しています。開発メンバーはLog、APMの使い方を習得し てください (後述) ◦ Monitor ▪

    メトリクスのしきい値を監視し、異常が検知された場合は Slackに通知。重要度の高いアラー トはPagerDutyにエスカレーション (本番環境のみ) ◦ Synthetic ▪ HTTPやgRPCによるWebアプリケーションの外形監視 (本番環境のみ) ◦ Log ▪ アプリケーションログの収集と検索を提供 ◦ APM ▪ アプリケーションのパフォーマンスを分析 25
  10. • インシデント管理ツールです。DatadogやSentryなどのSaaSからエスカレーションされた 障害をオンコール担当者に通知することができます • SREユニットではメンバー全員がオンコールに 参加しており、社内外のインフラを24/365体制 で監視しています • 代表的なオンコール対象メトリクスの例 ◦

    アプリケーションがHTTP 5xxを返した ◦ 外形監視が失敗 ◦ ヘルスチェックが失敗 • オンコールとしないメトリクスの例 ◦ ネットワークレイテンシーの上昇 ◦ CPU、メモリなどのリソース使用率上昇 PagerDuty 28
  11. • IPS (不正侵入防御)、IDS (不正侵入検知) の役割として、一部のプロダクトではト レンドマイクロ社のCloud Oneを導入しています • Cloud One

    Workload Securityを導入することで、不正プロ グラム対策 (マルウェア) や不正な通信をネットワークレベル で遮断することが可能となります ◦ Workload SecurityはAmazon EC2を保護します。サーバーレス環境 (FargateやLambdaなど) はサポート対象外となります Cloud One Workload Security 33
  12. THE TWELVE-FACTOR APP 38 1. コードベース バージョン管理されている 1つのコードベースと複数のデプロイ 2. 依存関係

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

    (Real User Monitoring) を導入することで、UX分析やエラー分析、パフォーマンス分析が可 能となります (例: Sentry Performance Monitoring、Datadog RUMなど) • アンチパターンの例 ◦ アセットがCDNから配信されていない ◦ アセットが圧縮 (あるいはバンドル) されていない ◦ 適切な画像フォーマットやリサイズが適用されていない ◦ SPAで起こりやすい問題 ▪ 構成されたアプリケーションがリロード時に HTTP 304を返している (HTTP 200を推奨) ▪ 同一エンド ポイントに多重リクエストが実行されている ▪ APIの例外が捕捉されず、画面全体の挙動に影響が発生 39
  14. • 秘匿値はソースコードに埋め込まないでください ◦ 秘匿値とは、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
  15. バックエンド 41 • 通信のタイムアウト ◦ アプリケーションがELB配下で動作する場合、 アプリケーションのタイムアウトは ELBのタイムアウト に依存する点に注意 が必要してください

    (デフォルト60秒) ◦ CSVファイルのダウンロードなど実行に時間がかかる処理は、メッセージキューの導入を検討してく ださい ◦ アプリケーションが外部と通信する際は、接続タイムアウトを考慮してください。 通信中はアプリケー ションのスレッドが専有されることを意識しましょう • データベースアクセス ◦ デッドロック、行ロックは Datadogアラートで検知します。アラート発生時は SRE側で一次調査を行 います ◦ スローログに関しては 1秒以上かかるクエリを CloudWatch Logsに記録しています (後述) ◦ クエリのパフォーマンスは、 Datadog APMからも確認することができます (後述)
  16. • 接続の再試行 (Exponential Backoff) ◦ 外部サービスと通信する際は、ネットワークや相手側のサーバーの問題で、一時的に接続が不安 定になる可能性があります。一定時間内にレスポンスがない場合は再試行する仕組みを検討して ください • アンチパターンの例

    ◦ N+1 (後述しますが、Datadog APMから確認可能です) ◦ 画像アップロード機能からアップロードされたファイル名が、サーバー側でリネームされず、オリジナ ルの名前でアクセスできてしまう (例: スクリーンショット.png) ◦ 画像が圧縮・リサイズされておらず、フロントエンドで画像一覧を表示する際のパフォーマンスが低 い ◦ ファットなAPIレスポンス (モデルデータをそのまま JSONに変換) ◦ URLパラメータを書き換えることで、本来権限のないページにアクセスできてしまう バックエンド 42
  17. • IPアドレスの制限 ◦ 外部から内部への通信 ▪ 外部ベンダーからリクエストを受け付ける APIエンドポイントを提供する場合、リクエスト送信 元 (ベンダー) のIPアドレスが静的なものか確認し、

    可能な限り接続元の制限を行ってくださ い ▪ IPアドレスはネットワークレベルでの遮断が望ましいため、ロードバランサー (WAF) 側での 制御を推奨とします。 IPアドレスの制限依頼は担当 SREにご連絡ください ◦ 内部から外部への通信 ▪ 接続先のベンダーによっては接続元の IPアドレスが制限される場合があります。 AWS内の サービスがインターネットに出る際の送信元 IPは固定となるため、SREから共有されたIPアド レスを案内してください バックエンド 45
  18. • アプリケーションのメンテナンス ◦ アプリケーションのリリース要件や、インフラ基盤のアップグレード要件に伴い、アプリケーションをメ ンテナンスモードに切り替えるケースがあります ◦ メンテナンス期間中はクローラー対策として HTTPステータスは503を返してください。 ▪ APIエンドポイントはJSON形式でエラーを返す実装を推奨します

    ◦ メンテナンス切り替えはアプリケーション側で実装するか、インフラで切り替えるか、システムの特性 に合わせて検討が必要です バックエンド 46 切り替え方法 メリット デメリット インフラ (ELB) ・アプリケーションレベルでの実装が不要 ・システム全体で一貫した切り替えが可能 複雑な条件でのメンテナンス切り替えは難しい可能 性がある アプリケーション より細かいアクセス制限が可能 ・複数のサービスで構成される場合、メンテナンスデ プロイに時間がかかる ・インフラ基盤側の障害に対応できない
  19. • 障害が発生した際のユーザー告知フローをあらかじめ決めておいてください ◦ 告知テンプレートの作成 ▪ 初期告知・更新告知・復旧告知 ◦ 障害発生時のエスカレーション ▪ 例:

    エンジニア→マネジャー→ 事業責任者による判断 → 広報・CSからの情報配信 ◦ 告知チャンネル ▪ サイト内での告知 ▪ メール配信 ▪ 社内アナウンス (Slackなど) ▪ SNS (Facebook、Xなど) 障害発生時のアナウンス (開発マネジャー) 47
  20. • 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
  21. CLI - MFAの登録 54 • IAMアカウントでAWSコン ソールにログイン後、右上のメニューから [セキュリ ティ認証情報] を開き、[多要素認証

    (MFA)] から仮想 デバイス (Google Authenticatorなど) を登録してくだ さい。 発行された識別子を控えておきます • 同じページ内の [アクセスキー] から [アクセスキ ーを作成] を選択してアクセスキーを発行して ください。 クレデンシャル情報ですので扱いには注意が 必要です
  22. 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
  23. # 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
  24. 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
  25. • AWSを操作する上で必要なアクセス権限を管理するサービス • 開発者のロールに合わせて最小限のポリシーを付与しています • 開発マネジャー ◦ Administrator相当の権限を付与します。ただしインフラ構成は IaCで管理しているため、原則的にリソースの変更依頼は SRE

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

    ◦ 1文字以上のアルファベット小文字 ◦ 1文字以上の数字 ◦ 1文字以上の記号 • Q: ログインはできたけど、全てのページで権限がないとエラーが出ます ◦ 初めに MFAの登録 を行ってください IAM 60
  27. • 静的コンテンツなどをCDN (Contents Delivery Network) 経由で高速配信する サービス • ELBの手前にはCloudFrontが配置されています ◦

    各プロダクトの最新の対応状況は担当 SREに確認してください ◦ フロントエンドをFargateから配信しているアプリケーションの場合、アセット (CSS、JavaScript、画 像など) をキャッシュ配信することが可能です • AWSのリージョン障害や、Fargateでコンテナが起動しない場合 (バックエンドから HTTP 502、503が返された場合) はCloudFrontが自動的にカスタムメンテナンス ページを表示します CloudFront 64
  28. • 仮想サーバーを構築するサービス ◦ メタップスのプロダクトは Fargateで稼働しているため、現在は管理用インスタンス (management-console)、開発検証用インスタンスを除いてほぼ利用していません • Q: インスタンスに接続するには? ◦

    セキュリティの観点から SSHポートは開放していません。 Session Managerを利用して接続してくだ さい ▪ インスタンスに接続する • Q: EBSのバックアップ体制は? ◦ 日単位で7世代 (デフォルト) 管理しています EC2 67
  29. • Q: 開発検証用インスタンスがほしい ◦ 起動テンプレートから EC2インスタンスを起動させてください ▪ インスタンスの起動は開発マネジャー (あるいはSRE) に依頼が必要です

    ▪ インスタンスからはRDSやElastiCacheに接続することができます ▪ セキュリティポリシー上、 EC2インスタンスからFargateに接続することはできません 。Fargate に接続するにはawsコマンドを利用してください ◦ 作業用インスタンスはコスト削減のため、デフォルトでは スポットインスタンスで起動 します。インスタ ンスはスポット容量の不足や、入札価格次第でインスタンス終了する可能性があります。 オンデマ ンドで常にインスタンスを起動させておきたい場合は担当 SREにご連絡ください EC2 68
  30. ECS 69 • スケーラブルかつフルマネージドなDockerコンテナの実行環境を提供するサービ ス • ECSには、ECS on EC2とFargateがありますが、社内プロダクトは全てFargate、 デプロイ方式はローリングデプロイで統一しています

    • サーバーの負荷に応じてオートスケールする仕組みを導入しています • アプリケーションからSTDOUTに出力されるログはDatadog Log、S3に配送されま す ◦ 利便性の観点から通常は Datadog Logの利用を推奨します
  31. ECS • Q: コンテナに接続するには? ◦ サービスのコンテナに接続する ◦ Fargate接続クライアントツールもあります ▪ https://github.com/metaps/connect_to_fargate

    • Q: タスク定義ファイルの作成方法が分からない ◦ ベースとなるタスク定義は担当 SREが作成します ◦ タスクパラメータの詳細は、 タスク定義のベストプラクティス を参照してください 73
  32. ECS - genova 74 • デプロイにはgenovaを利用します ◦ https://github.com/metaps/genova • Q:

    どのようなデプロイ形式をサポートしますか? ◦ CLI、Slack、GitHub Actionsによるデプロイ ◦ サービス、スケジュールタスク、スタンドアロンタスクの実行をサポート ◦ ECS on EC2、Fargateに対応 • genovaはOSSです。使い方の質問はSlack、機能要望はIssueにお願いします。も ちろんPRも大歓迎です!
  33. • システムがスケールするにつれて、デプロイサイクルも複雑化します。genovaは サービスやスケジュールタスクをステップ実行する仕組みを提供するため、デプロ イの自動化が可能です ◦ ステージング環境へのデプロイ : GitHub Actions (推奨)

    ▪ デプロイをトリガーとするブランチとデプロイステップを定義しておくことで、コードがプッシュさ れたタイミングでデプロイを自動実行する ◦ 本番環境へのデプロイ : genova Workflow (推奨) ▪ ワークフローにデプロイステップを定義しておき、デプロイ時にワークフローを指定する形でデ プロイを実行する • リリース時に複数サービスのデプロイや、スタンドアロンタスクを実行するプロダクト においては、デプロイの自動化を強く推奨します ECS - genova (自動化) 78
  34. • 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
  35. レイヤー 命名規則 担当 パラメータの管理 インフラ (環境に依存しない) /{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
  36. • フルマネージド型のリレーショナルデータベースサービス • メタップスでは標準データベースとしてAurora MySQL 2 (または3) を採用していま す。順次各プロダクトのアップグレードを実施していますが、優先希望があればご 連絡ください

    • アプリケーションからRDSに接続する際のエンドポイント名は、クラスター名ではな く、サービスディスカバリで割り当てられた名前を指定してください ◦ 例: db-writer.re-shine.internal • データベースの負荷軽減のため、書き込みはプライマリ、参照クエリはレプリカの使 用を検討してください RDS 87
  37. • データベースへの接続にはコネクションプーリングを検討してください ◦ 適切なプーリングサイズの設計は担当 SREに相談してください ▪ Aurora MySQL DB インスタンスへの最大接続数

    • ステートレスなアプリケーション (Lambdaなど) からRDSに接続する際はコネクショ ンが保持されない点に注意してください。コネクションプール可能なRDS Proxyの 導入を検討しましょう • アプリケーションとRDSとの接続はデフォルトでSSL通信が無効です。通信の暗号 化を推奨します • SSL/TLS を使用した DB クラスターへの接続の暗号化 RDS 88
  38. • Q: バックアップ体制は? ◦ 日単位で7世代 (デフォルト) 管理しています • Q: データベースに秘匿性の高いデータを保存するには?

    ◦ パスワードはハッシュ化、複合が必要なデータは KMSの利用を検討してください • Q: EC2やFargateからmysqlコマンドでデータベースに接続したい ◦ mysqlコマンドでデータベースに接続する • Q: ローカル環境からRDSに接続するには? ◦ SSMとInstance Connectを用いたMySQLへの接続 RDS 89
  39. • バックアップ方法には、mysqldumpなどのコマンドベースのバックアップと、RDSの スナップショット機能を用いたバックアップがあります。用途に合わせて使い分けて ください RDS 90 コマンドベース スナップショット データベースへの負荷 高

    低 バックアップ速度 実行環境による AWSインフラストラクチャで実行 安全性 実行環境による 高 バックアップ対象 データベース データベースを含むインフラストラクチャレベル 復旧速度 速い 遅い (クラスターを構築するため、数十分以上 の時間を要する) 開発者による実行 可能 (プロダクトの運用ポリシーによる) 不可能 (開発マネジャー、SREのみ)
  40. • スローログを確認するには、CloudWatch Logs Insightsを利用してください ◦ AWSコンソールからCloudWatch Logsを開き、[ログのインサイト] を選択 ◦ [ロググループを選択

    ] にスローログのロググループを指定 ▪ 例: /aws/cluster/production/slowquery ◦ [クエリの実行] を押下 • 遅いクエリを検出したらクエリの実行 計画 (EXPLAIN) を確認し、クエリの チューニングやインデックスの付け替え を検討してください RDS 91
  41. • オブジェクトストレージサービス ◦ アプリケーションから配信するアセットは S3からの配信を検討してください • 認証されたユーザーにのみオブジェクトを返却したい場合は、署名付きURL (Pre-Signed URL) を利用してください

    ◦ 一覧画面などで署名付き URLのリストを表示すると、レスポンスまでに時間がかかる可能性があり ます。CloudFrontの署名付きURL発行や、フロントエンドの遅延ローディング (Lazy Loading) 実装 を検討してください • 恒久的に残す必要のないファイル (ログ、一時ファイルなど) はセキュリティの観点 からも定期的に削除することを推奨します ◦ S3のライフサイクルルールを使うことで不要なオブジェクトの定期的な削除が可能です S3 94
  42. • フロントエンドアプリケーション配信サービス ◦ Route 53 + CloudFront + S3を組み合わせた機能を提供します •

    Amplifyでは環境変数を扱うことができますが、秘匿値は環境変数に含めるべきで はありません。環境シークレットの利用を検討してください ◦ 環境シークレットを設定 • コンテンツ配信を最適化するためのパフォーマンスモード機能があります ◦ パフォーマンスモードを有効化することで、コンテンツが CloudFrontから配信されます ◦ カスタムヘッダーを利用することで、特定のパス以下のみキャッシュ制御が可能です Amplify 95
  43. 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への 移行が必要です
  44. SQS 99 • マネージド型メッセージキューサービス ◦ SQSを導入することで、メッセージの送信と受信側の処理を非同期化することができます • Railsには同等のサービスとしてSidekiqがありますが、SREユニットではAWSを使 う上でSQSの利用を推奨しています ◦

    SidekiqをECSで利用する場合、タスクの停止で実行中のジョブが消失してしまう ◦ SQSはDatadogでキューの状態を監視可能 ▪ Sidekiqは上位プランへのアップグレードが必要 ◦ SQS (EventBridge) をトリガーにLambdaやFargateを起動することができる
  45. • WebアプリケーションをXSSやSQLインジェクションといった一般的な攻撃から保護する サービス • DDoS対策に加え、Fortinet社のマネージドルールセットを契約しています (一部プロダクト を除く) ◦ Cloud WAF

    Comparison Using Real-World Attacks • WAFがリクエストをブロックした場合は、クライアントにHTTP 403を返します • WAFはごく稀に誤判定を起こす可能性があります ◦ 例: HTMLタグやSQLをPOSTするフォームなど ◦ 特定のリクエストパスをWAFから除外することが可能です • 脆弱性試験を実施する際は一時的にルールを除外する必要があります WAF / Shield 101
  46. • Q: アプリケーションログはどのようにDatadog Logに転送されますか? ◦ 標準出力に吐かれたログを FireLens (FluentBit) がログクラスター (Fluentd)

    に送信。各サービス から収集したログを整形後、 Datadog LogsやS3に転送します ◦ 標準出力のフォーマットは JSONを推奨します。アプリケーションのログ送信周りは SREユニットに て実装 (あるいは開発ユニットに依頼 ) する形となります Log 105
  47. • 全てのサービス (≒ コンテナ) に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
  48. セキュリティの責任分界点 保護対象 開発ユニット SREユニット データの保護 ◯ 秘匿値の管理 ◯ 通信の暗号化・ストレージの暗号化 アプリケーションコード

    ◯ ☓ 静的解析ツールの導入を検討中 アプリケーションのパッケージ管理 ◯ EOSLの管理 ◯ 脆弱性の自動検知・修復の仕組みを提供 Dockerイメージ ◯ ◯ イメージに対するセキュリティパッチ適用 OS ☓ ◯ IPS / IDSの運用 ☓ ◯ 119
  49. 2023年のロードマップ • AWSコストの異常検知 ◦ MLベースでコスト異常のアラート通知を導入します • AWS Graviton (ARM)プロセッサへの移行 ◦

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