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

by ekanai

Slide 1

Slide 1 text

TimeTree の SRE が海外展開においてやったこと＆やってないこと

Slide 2

Slide 2 text

TimeTree の紹介予定をつくって、共有してコミュニケーションできるアプリです    TimeTreeは、予定の共有と相談が驚くほど簡単にできるコミュニケーションアプリです。カレンダーひとつで、決まった予定の共有も、これからの楽しみな予定の相談も簡単にできます。 

Slide 3

Slide 3 text

自己紹介名前：金井栄喜（カナイエイキ）所属：株式会社TimeTree 役割： SRE チームリードニックネーム： miu 趣味：ラーメン作り, DIY 家族構成：妻と猫2匹と私

Slide 4

Slide 4 text

目次 - やったこと - やってないこと

Slide 5

Slide 5 text

やったこと

Slide 6

Slide 6 text

やったこと - ネットワークパフォーマンス改善 - セキュリティ

Slide 7

Slide 7 text

やったこと - ネットワークパフォーマンス改善 - セキュリティ

Slide 8

Slide 8 text

ネットワークパフォーマンス改善解決したい問題 - 物理的な距離があるほど通信する距離が増加する - 単純にネットワーク時間が増加する - 離れている海外のユーザーほど影響がある - 海外ユーザーのボリュームゾーンは結構離れている

Slide 9

Slide 9 text

ネットワークパフォーマンス改善 - CloudFront を利用した改善 - BackendAPI 改善

Slide 10

Slide 10 text

ネットワークパフォーマンス改善 - CloudFront を利用した改善 - BackendAPI 改善

Slide 11

Slide 11 text

ネットワークパフォーマンス改善 CloudFront を利用したネットワークパフォーマンスの改善どうやって解決するか - CloudFront を利用することで AWS で最適化されたネットワークを利用できる - ユーザーにより近いエッジロケーションから最適化されたネットワークを利用することでパフォーマンスの向上をはかる

Slide 12

Slide 12 text

ネットワークパフォーマンス改善 CloudFront を利用したネットワークパフォーマンスの改善 CloudFront とは - Amazon Web Services（AWS）が提供するグローバルなコンテンツ配信ネットワーク（CDN）サービス - AWS ネットワークバックボーンを介して AWS リージョンに接続 - 450 以上の Point of Presence のグローバルネットワークと 48 か国の 90 以上の都市にある 13 のリージョンレベルのエッジキャッシュ

Slide 13

Slide 13 text

ネットワークパフォーマンス改善 CloudFront を利用したネットワークパフォーマンスの改善参照元 https://aws.amazon.com/jp/cloudfront/features/?whats-new-cloudfront.sort-by=item.addi tionalFields.postDateTime&whats-new-cloudfront.sort-order=desc

Slide 14

Slide 14 text

ネットワークパフォーマンス改善 CloudFront を利用したネットワークパフォーマンスの改善 AWS ネットワークバックボーンを介して AWS リージョンに接続 - エッジロケーションからサーバーまで AWS で最適化されたネットワークを利用して通信することが可能 - -> CloudFront を利用しないグローバルなインターネットからなアクセスよりもネットワークパフォーマンスの改善が見込まれる

Slide 15

Slide 15 text

ネットワークパフォーマンス改善 CloudFront を利用したネットワークパフォーマンスの改善対応内容 - インフラ構成変更 - メインの対応 - クライアント IP 取得方法変更 - メインの対応をした際にアプリケーションに影響を与えないための対応

Slide 16

Slide 16 text

ネットワークパフォーマンス改善 CloudFront を利用したネットワークパフォーマンスの改善インフラ構成変更変更前変更後

Slide 17

Slide 17 text

ネットワークパフォーマンス改善 CloudFront を利用したネットワークパフォーマンスの改善クライアント IP 取得方法変更 - アプリケーションのログとしてクライアント IP が必要 - IP 自体は機密情報としてセキュリティ対策はバッチリです - 今までは LB -> Fargate だった - 変更後は CloudFront -> LB -> Fargate になるため Fargate に到達するまでの経路が増えた - 多段での IP 取得方法に変更する必要がある

Slide 18

Slide 18 text

ネットワークパフォーマンス改善 - CloudFront を利用した改善 - BackendAPI 改善

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

Slide 21

Slide 21 text

ネットワークパフォーマンス改善 Backend API 改善 (呼び出し回数の最適化) 対応内容 - 一覧 API の取得件数の増加 - クライアントサイドでの修正が必要かどうか Frontend チームと相談 - 取得件数を変更（例 100 件 -> 200 件） - APM で API の遅延具合を確認 - SQL の見直し

Slide 22

Slide 22 text

Slide 23

Slide 23 text

ネットワークパフォーマンス改善 Backend API 改善 (動的エンドポイントをキャッシュできるように変更) 対応内容 - Backend API アプリケーションを変更 - CloudFront にキャッシュの設定を追加

Slide 24

Slide 24 text

ネットワークパフォーマンス改善 Backend API 改善 (動的エンドポイントをキャッシュできるように変更) 対応内容(Backend API アプリケーションを変更) - キャッシュに適したリクエストパラメータ設計&実装

Slide 25

Slide 25 text

ネットワークパフォーマンス改善 Backend API 改善 (動的エンドポイントをキャッシュできるように変更) 気を付けること(Backend API アプリケーションを変更) - 動的 API をキャッシュする - 機密情報が含まれている可能性 - セッション情報など - 十分に設計やテストを実施した上で移行していく

Slide 26

Slide 26 text

ネットワークパフォーマンス改善 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

Slide 27

Slide 27 text

ネットワークパフォーマンス改善 Backend API 改善 (動的エンドポイントをキャッシュできるように変更) 気を付けること(CloudFront の設定変更) - Behavior の優先順位 - キャッシュキー

Slide 28

Slide 28 text

ネットワークパフォーマンス改善なぜこのような対応を実施したか - コスパがよい - CFRC(CloudFront Reserved Capacity) の検討時期でもあったためタイミング的にちょうどよかった - 対応後の運用コストにもほぼ影響なし

Slide 29

Slide 29 text

ネットワークパフォーマンス改善結果 - クライアントの APM 未導入なので具体的な数値はわからず - パフォーマンスに関する海外からのお問い合わせはなし

Slide 30

Slide 30 text

ネットワークパフォーマンス改善気にしたいこと - CloudFront の料金 - サービス開始時は問題ないと思う - スケールしてきてリクエスト数が増加してくると思いのほか料金がかかる可能性 - AWS の担当の方とよく相談をして対応していくと解消しやすいです

Slide 31

Slide 31 text

やったこと - ネットワークパフォーマンス改善 - セキュリティ

Slide 32

Slide 32 text

セキュリティ解決したい問題 - ユーザーの不安を少しでも解消する - 日本とは異なる法律への準拠

Slide 33

Slide 33 text

セキュリティ - 基本的な部分の見直し - GDPR

Slide 34

Slide 34 text

セキュリティ - 基本的な部分の見直し - GDPR

Slide 35

Slide 35 text

セキュリティ基本的な部分の見直しどうやって解決するか - 暗号化やネットワーク構成などの見直し - S3 やデータベースなど暗号化がされているか - インターネットから進入可能な環境はないか - セキュリティ関連対応状況がすぐに確認できる環境 - AWS Security Hub の導入 - 心配になったユーザーのお問合せに即座に誰でも対応 - 会社の機密情報保持状況について部分的な確証

Slide 36

Slide 36 text

セキュリティ基本的な部分の見直し対応内容 - AWS Security Hub 導入 - AWS リソースがルールから外れていないか自動でチェック - IaC リファクタリング - より迅速に対応できるように - SCP 作成 - ガードレールでリスク回避 - パブリックネットワーク環境廃止

Slide 37

Slide 37 text

セキュリティ基本的な部分の見直し Security Hub はこんな見た目（一部）

Slide 38

Slide 38 text

セキュリティ - 基本的な部分の見直し - GDPR

Slide 39

Slide 39 text

セキュリティ GDPR どうやって解決するか - とにかくやらなくてはならないことの洗い出しと対応（以下抜粋） - ユーザー所有と見なされるデータの範囲 - データ - ログ - 画像 etc - ユーザーが所有するデータのダウンロード - 解約したユーザーデータの保持期間 - etc

Slide 40

Slide 40 text

セキュリティ GDPR 対応内容 - データダウンロード用環境を用意 - S3 - ダウンロード機能実装 - 問い合わせベースでのダウンロード機能 - データ保持期間の徹底 - S3 ライフサイクル - 解約後のデータ削除機能 - バッチ処理作成

Slide 41

Slide 41 text

セキュリティなぜこのような対応を実施したか - やらなくてはならない部分 - ユーザーからの信頼性 - 海外ユーザーの方が日本ユーザーよりもセキュリティ状況に敏感な傾向 - バウンティハンター - とても大事なことでありサービスのグロースと良いタイミングだった

Slide 42

Slide 42 text

セキュリティおまけ - 中国に本格参入するか？みたいな話が内輪で上がったことも - 中国サイバーセキュリティー法 - Android 参入の難易度 - 中国以外のデータとの住み分け - etc - この時は無理そうだねと立ち消えしました

Slide 43

Slide 43 text

やってないこと

Slide 44

Slide 44 text

やってないこと - マルチリージョン対応 - クライアントモニタリング

Slide 45

Slide 45 text

なぜやっていないのか - 全体を通して - 会社における海外展開の重要度 - 基本的な構成や運用のリファクタリングを優先やってないこと

Slide 46

Slide 46 text

なぜやっていないのか (マルチリージョン) - データ量の増加へのアプローチ - まずはシャーディング - 人的リソース - 対応後の運用含め一人でできるのか - データベース同期ラグを考慮した改修 - より優先度の高い改善や新規機能 - 会社として優先度がそこまで高くない状況でのみんなを巻き込んだ開発やってないこと

Slide 47

Slide 47 text

なぜやっていないのか (クライアントモニタリング) - 費用 - ちょっと試しにやってみたけどかなりのデータ量に - 工夫が必要 - 一歩踏み込めなかった甘さ - バックエンドは APM を利用した分散トレーシングを導入していてちょっと満足していた - クライアントは GA でなんとなくモニタリングしていた - いざ試しに導入してみると色々問題もありもっと早く動いていれば状況は変わっていたかもやってないこと

Slide 48

Slide 48 text

まとめ

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

宣伝

Slide 51

Slide 51 text

採用イベント開催予定です！ - 6月21日ビジネスDiv　https://bit.ly/3qx10kZ - 6月27日プロダクトDiv　https://bit.ly/42xTV1e - 7月4日エンジニア（Tech Talk）　https://bit.ly/3oNrK0m 宣伝

Slide 52

Slide 52 text

ありがとうございました連絡先: 会社名株式会社TimeTree （TimeTree, Inc.）郵便番号 160-0023 東京都新宿区西新宿 6丁目6-3 新宿国際ビルディング新館 503 [email protected] https://timetreeapp.com/intl/ja/ corporate