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

TimeTree の SRE が海外展開においてやったこと&やってないこと by【TimeTr...

ekanai
June 09, 2023

TimeTree の SRE が海外展開においてやったこと&やってないこと by【TimeTree × みてね勉強会】 グローバル対応への挑戦 〜SRE/インフラ編〜

ekanai

June 09, 2023
Tweet

More Decks by ekanai

Other Decks in Technology

Transcript

  1. ネットワークパフォーマンス改善 CloudFront を利用したネットワークパフォーマンスの改善 CloudFront とは - Amazon Web Services(AWS)が提供するグローバルなコンテンツ配信ネット ワーク(CDN)サービス

    - AWS ネットワークバックボーンを介して AWS リージョンに接続 - 450 以上の Point of Presence のグローバルネットワークと 48 か国の 90 以上 の都市にある 13 のリージョンレベルのエッジキャッシュ
  2. ネットワークパフォーマンス改善 CloudFront を利用したネットワークパフォーマンスの改善 AWS ネットワークバックボーンを介して AWS リージョンに接続 - エッジロケーションからサーバーまで AWS

    で最適化されたネットワークを利用し て通信することが可能 - -> CloudFront を利用しないグローバルなインターネットからなアクセスよりも ネットワークパフォーマンスの改善が見込まれる
  3. ネットワークパフォーマンス改善 CloudFront を利用したネットワークパフォーマンスの改善 クライアント IP 取得方法変更 - アプリケーションのログとしてクライアント IP が必要

    - IP 自体は機密情報としてセキュリティ対策はバッチリです - 今までは LB -> Fargate だった - 変更後は CloudFront -> LB -> Fargate になるため Fargate に到達するまでの 経路が増えた - 多段での IP 取得方法に変更する必要がある
  4. ネットワークパフォーマンス改善 Backend API 改善 どうやって解決するか - 呼び出し回数の最適化 - 一覧系の API

    の取得件数の最適化 - API 呼び出し回数が減らせる可能性 -> 遠隔地からのネットワーク時間の短縮 - 動的 API をキャッシュできるように変更 - CloudFront でキャッシュする - API 結果がエッジロケーションから返却されることでネットワーク時間の短縮 - あわよくばサーバーの負荷軽減
  5. ネットワークパフォーマンス改善 Backend API 改善 どうやって解決するか - 呼び出し回数の最適化 - 一覧系の API

    の取得件数の最適化 - API 呼び出し回数が減らせる可能性 -> 遠隔地からのネットワーク時間の短縮 - 動的 API をキャッシュできるように変更 - CloudFront でキャッシュする - API 結果がエッジロケーションから返却されることでネットワーク時間の短縮 - あわよくばサーバーの負荷軽減
  6. ネットワークパフォーマンス改善 Backend API 改善 (呼び出し回数の最適化) 対応内容 - 一覧 API の取得件数の増加

    - クライアントサイドでの修正が必要かどうか Frontend チームと相談 - 取得件数を変更(例 100 件 -> 200 件) - APM で API の遅延具合を確認 - SQL の見直し
  7. ネットワークパフォーマンス改善 Backend API 改善 どうやって解決するか - 呼び出し回数の最適化 - 一覧系の API

    の取得件数の最適化 - API 呼び出し回数が減らせる可能性 -> 遠隔地からのネットワーク時間の短縮 - 動的 API をキャッシュできるように変更 - CloudFront でキャッシュする - API 結果がエッジロケーションから返却されることでネットワーク時間の短縮 - あわよくばサーバーの負荷軽減
  8. ネットワークパフォーマンス改善 Backend API 改善 (動的エンドポイントをキャッシュできるように変更) 気を付けること(Backend API アプリケーションを変更) - 動的

    API をキャッシュする - 機密情報が含まれている可能性 - セッション情報など - 十分に設計やテストを実施した上で移行していく
  9. ネットワークパフォーマンス改善 Backend API 改善 (動的エンドポイントをキャッシュできるように変更) 対応内容 (CloudFront の設定変更) 変更前 Precedence

    Path pattern Cache policy 1 Default(*) CachingDisabled 変更後 Precedence Path pattern Cache policy 1 /cache/shitai/path CachingOptimized 2 Default(*) CachingDisabled Behavior
  10. セキュリティ 基本的な部分の見直し どうやって解決するか - 暗号化やネットワーク構成などの見直し - S3 やデータベースなど暗号化がされているか - インターネットから進入可能な環境はないか

    - セキュリティ関連対応状況がすぐに確認できる環境 - AWS Security Hub の導入 - 心配になったユーザーのお問合せに即座に誰でも対応 - 会社の機密情報保持状況について部分的な確証
  11. セキュリティ 基本的な部分の見直し 対応内容 - AWS Security Hub 導入 - AWS

    リソースがルールから外れていないか自動でチェック - IaC リファクタリング - より迅速に対応できるように - SCP 作成 - ガードレールでリスク回避 - パブリックネットワーク環境廃止
  12. セキュリティ GDPR 対応内容 - データダウンロード用環境を用意 - S3 - ダウンロード機能実装 -

    問い合わせベースでのダウンロード機能 - データ保持期間の徹底 - S3 ライフサイクル - 解約後のデータ削除機能 - バッチ処理作成
  13. なぜやっていないのか (マルチリージョン) - データ量の増加へのアプローチ - まずはシャーディング - 人的リソース - 対応後の運用含め一人でできるのか

    - データベース同期ラグを考慮した改修 - より優先度の高い改善や新規機能 - 会社として優先度がそこまで高くない状況でのみんなを巻き込んだ開発 やってないこと
  14. なぜやっていないのか (クライアントモニタリング) - 費用 - ちょっと試しにやってみたけどかなりのデータ量に - 工夫が必要 - 一歩踏み込めなかった甘さ

    - バックエンドは APM を利用した分散トレーシングを導入していてちょっと満足していた - クライアントは GA でなんとなくモニタリングしていた - いざ試しに導入してみると色々問題もありもっと早く動いていれば状況は変わっていたかも やってないこと
  15. - できることとできないことが存在する - 人やお金の問題 - 会社が求めるもの - まずは色々考えてみることが大切 - 考えないと始まらない

    - 海外のユーザーはどう感じているか想像してみる - 本当にやった方がいいと思うことは会社全体を巻き込んで - 会社の状況を見てリソース的にいけそうな雰囲気など判断して声を上げてみる - 社内に落ちている色々なデータなど利用したり - すぐにできてしまうことはやっちゃうのもあり - チームや自分の責任範囲ですぐにできてしまうものなどは積極的に導入してしまう - 納得や効果が得られなければロールバックすれば良い まとめ