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

Transcript

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

3. 自己紹介 名前：金井 栄喜（カナイ エイキ） 所属：株式会社TimeTree 役割： SRE チームリード ニックネーム： miu 趣味：ラーメン作り, DIY 家族構成：妻と猫2匹と私
4. 目次 - やったこと - やってないこと
5. やったこと
6. やったこと - ネットワークパフォーマンス改善 - セキュリティ
7. やったこと - ネットワークパフォーマンス改善 - セキュリティ
8. ネットワークパフォーマンス改善 解決したい問題 - 物理的な距離があるほど通信する距離が増加する - 単純にネットワーク時間が増加する - 離れている海外のユーザーほど影響がある - 海外ユーザーのボリュームゾーンは結構離れている
9. ネットワークパフォーマンス改善 - CloudFront を利用した改善 - BackendAPI 改善
10. ネットワークパフォーマンス改善 - CloudFront を利用した改善 - BackendAPI 改善
11. ネットワークパフォーマンス改善 CloudFront を利用したネットワークパフォーマンスの改善 どうやって解決するか - CloudFront を利用することで AWS で最適化されたネットワークを利用できる - ユーザーにより近いエッジロケーションから最適化されたネットワークを利用す ることでパフォーマンスの向上をはかる
12. ネットワークパフォーマンス改善 CloudFront を利用したネットワークパフォーマンスの改善 CloudFront とは - Amazon Web Services（AWS）が提供するグローバルなコンテンツ配信ネット ワーク（CDN）サービス - AWS ネットワークバックボーンを介して AWS リージョンに接続 - 450 以上の Point of Presence のグローバルネットワークと 48 か国の 90 以上 の都市にある 13 のリージョンレベルのエッジキャッシュ
13. ネットワークパフォーマンス改善 CloudFront を利用したネットワークパフォーマンスの改善 参照元 https://aws.amazon.com/jp/cloudfront/features/?whats-new-cloudfront.sort-by=item.addi tionalFields.postDateTime&whats-new-cloudfront.sort-order=desc
14. ネットワークパフォーマンス改善 CloudFront を利用したネットワークパフォーマンスの改善 AWS ネットワークバックボーンを介して AWS リージョンに接続 - エッジロケーションからサーバーまで AWS で最適化されたネットワークを利用し て通信することが可能 - -> CloudFront を利用しないグローバルなインターネットからなアクセスよりも ネットワークパフォーマンスの改善が見込まれる
15. ネットワークパフォーマンス改善 CloudFront を利用したネットワークパフォーマンスの改善 対応内容 - インフラ構成変更 - メインの対応 - クライアント IP 取得方法変更 - メインの対応をした際にアプリケーションに影響を与えないための対応
16. ネットワークパフォーマンス改善 CloudFront を利用したネットワークパフォーマンスの改善 インフラ構成変更 変更前 変更後
17. ネットワークパフォーマンス改善 CloudFront を利用したネットワークパフォーマンスの改善 クライアント IP 取得方法変更 - アプリケーションのログとしてクライアント IP が必要 - IP 自体は機密情報としてセキュリティ対策はバッチリです - 今までは LB -> Fargate だった - 変更後は CloudFront -> LB -> Fargate になるため Fargate に到達するまでの 経路が増えた - 多段での IP 取得方法に変更する必要がある
18. ネットワークパフォーマンス改善 - CloudFront を利用した改善 - BackendAPI 改善
19. ネットワークパフォーマンス改善 Backend API 改善 どうやって解決するか - 呼び出し回数の最適化 - 一覧系の API の取得件数の最適化 - API 呼び出し回数が減らせる可能性 -> 遠隔地からのネットワーク時間の短縮 - 動的 API をキャッシュできるように変更 - CloudFront でキャッシュする - API 結果がエッジロケーションから返却されることでネットワーク時間の短縮 - あわよくばサーバーの負荷軽減
20. ネットワークパフォーマンス改善 Backend API 改善 どうやって解決するか - 呼び出し回数の最適化 - 一覧系の API の取得件数の最適化 - API 呼び出し回数が減らせる可能性 -> 遠隔地からのネットワーク時間の短縮 - 動的 API をキャッシュできるように変更 - CloudFront でキャッシュする - API 結果がエッジロケーションから返却されることでネットワーク時間の短縮 - あわよくばサーバーの負荷軽減
21. ネットワークパフォーマンス改善 Backend API 改善 (呼び出し回数の最適化) 対応内容 - 一覧 API の取得件数の増加 - クライアントサイドでの修正が必要かどうか Frontend チームと相談 - 取得件数を変更（例 100 件 -> 200 件） - APM で API の遅延具合を確認 - SQL の見直し
22. ネットワークパフォーマンス改善 Backend API 改善 どうやって解決するか - 呼び出し回数の最適化 - 一覧系の API の取得件数の最適化 - API 呼び出し回数が減らせる可能性 -> 遠隔地からのネットワーク時間の短縮 - 動的 API をキャッシュできるように変更 - CloudFront でキャッシュする - API 結果がエッジロケーションから返却されることでネットワーク時間の短縮 - あわよくばサーバーの負荷軽減
23. ネットワークパフォーマンス改善 Backend API 改善 (動的エンドポイントをキャッシュできるように変更) 対応内容 - Backend API アプリケーションを変更 - CloudFront にキャッシュの設定を追加
24. ネットワークパフォーマンス改善 Backend API 改善 (動的エンドポイントをキャッシュできるように変更) 対応内容(Backend API アプリケーションを変更) - キャッシュに適したリクエストパラメータ設計&実装
25. ネットワークパフォーマンス改善 Backend API 改善 (動的エンドポイントをキャッシュできるように変更) 気を付けること(Backend API アプリケーションを変更) - 動的 API をキャッシュする - 機密情報が含まれている可能性 - セッション情報など - 十分に設計やテストを実施した上で移行していく
26. ネットワークパフォーマンス改善 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
27. ネットワークパフォーマンス改善 Backend API 改善 (動的エンドポイントをキャッシュできるように変更) 気を付けること(CloudFront の設定変更) - Behavior の優先順位 - キャッシュキー
28. ネットワークパフォーマンス改善 なぜこのような対応を実施したか - コスパがよい - CFRC(CloudFront Reserved Capacity) の検討時期でもあったためタイミング的 にちょうどよかった - 対応後の運用コストにもほぼ影響なし
29. ネットワークパフォーマンス改善 結果 - クライアントの APM 未導入なので具体的な数値はわからず - パフォーマンスに関する海外からのお問い合わせはなし
30. ネットワークパフォーマンス改善 気にしたいこと - CloudFront の料金 - サービス開始時は問題ないと思う - スケールしてきてリクエスト数が増加してくると思いのほか料金がかかる可能性 - AWS の担当の方とよく相談をして対応していくと解消しやすいです
31. やったこと - ネットワークパフォーマンス改善 - セキュリティ
32. セキュリティ 解決したい問題 - ユーザーの不安を少しでも解消する - 日本とは異なる法律への準拠
33. セキュリティ - 基本的な部分の見直し - GDPR
34. セキュリティ - 基本的な部分の見直し - GDPR
35. セキュリティ 基本的な部分の見直し どうやって解決するか - 暗号化やネットワーク構成などの見直し - S3 やデータベースなど暗号化がされているか - インターネットから進入可能な環境はないか - セキュリティ関連対応状況がすぐに確認できる環境 - AWS Security Hub の導入 - 心配になったユーザーのお問合せに即座に誰でも対応 - 会社の機密情報保持状況について部分的な確証
36. セキュリティ 基本的な部分の見直し 対応内容 - AWS Security Hub 導入 - AWS リソースがルールから外れていないか自動でチェック - IaC リファクタリング - より迅速に対応できるように - SCP 作成 - ガードレールでリスク回避 - パブリックネットワーク環境廃止
37. セキュリティ 基本的な部分の見直し Security Hub はこんな見た目（一部）
38. セキュリティ - 基本的な部分の見直し - GDPR
39. セキュリティ GDPR どうやって解決するか - とにかくやらなくてはならないことの洗い出しと対応（以下抜粋） - ユーザー所有と見なされるデータの範囲 - データ - ログ - 画像 etc - ユーザーが所有するデータのダウンロード - 解約したユーザーデータの保持期間 - etc
40. セキュリティ GDPR 対応内容 - データダウンロード用環境を用意 - S3 - ダウンロード機能実装 - 問い合わせベースでのダウンロード機能 - データ保持期間の徹底 - S3 ライフサイクル - 解約後のデータ削除機能 - バッチ処理作成
41. セキュリティ なぜこのような対応を実施したか - やらなくてはならない部分 - ユーザーからの信頼性 - 海外ユーザーの方が日本ユーザーよりもセキュリティ状況に敏感な傾向 - バウンティハンター - とても大事なことでありサービスのグロースと良いタイミングだった
42. セキュリティ おまけ - 中国に本格参入するか？みたいな話が内輪で上がったことも - 中国サイバーセキュリティー法 - Android 参入の難易度 - 中国以外のデータとの住み分け - etc - この時は無理そうだねと立ち消えしました
43. やってないこと
44. やってないこと - マルチリージョン対応 - クライアントモニタリング
45. なぜやっていないのか - 全体を通して - 会社における海外展開の重要度 - 基本的な構成や運用のリファクタリングを優先 やってないこと
46. なぜやっていないのか (マルチリージョン) - データ量の増加へのアプローチ - まずはシャーディング - 人的リソース - 対応後の運用含め一人でできるのか - データベース同期ラグを考慮した改修 - より優先度の高い改善や新規機能 - 会社として優先度がそこまで高くない状況でのみんなを巻き込んだ開発 やってないこと
47. なぜやっていないのか (クライアントモニタリング) - 費用 - ちょっと試しにやってみたけどかなりのデータ量に - 工夫が必要 - 一歩踏み込めなかった甘さ - バックエンドは APM を利用した分散トレーシングを導入していてちょっと満足していた - クライアントは GA でなんとなくモニタリングしていた - いざ試しに導入してみると色々問題もありもっと早く動いていれば状況は変わっていたかも やってないこと
48. まとめ
49. - できることとできないことが存在する - 人やお金の問題 - 会社が求めるもの - まずは色々考えてみることが大切 - 考えないと始まらない - 海外のユーザーはどう感じているか想像してみる - 本当にやった方がいいと思うことは会社全体を巻き込んで - 会社の状況を見てリソース的にいけそうな雰囲気など判断して声を上げてみる - 社内に落ちている色々なデータなど利用したり - すぐにできてしまうことはやっちゃうのもあり - チームや自分の責任範囲ですぐにできてしまうものなどは積極的に導入してしまう - 納得や効果が得られなければロールバックすれば良い まとめ
50. 宣伝
51. 採用イベント開催予定です！ - 6月21日 ビジネスDiv　https://bit.ly/3qx10kZ - 6月27日 プロダクトDiv　https://bit.ly/42xTV1e - 7月4日 エンジニア（Tech Talk）　https://bit.ly/3oNrK0m 宣伝
52. ありがとうございました 連絡先: 会社名 株式会社TimeTree （TimeTree, Inc.） 郵便番号 160-0023 東京都新宿区西新宿 6丁目6-3 新 宿国際ビルディング 新館 503 miu@timetreeapp.com https://timetreeapp.com/intl/ja/ corporate