Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
TimeTree の SRE が海外展開においてやったこと&やってないこと by【TimeTr...
Search
ekanai
June 09, 2023
Technology
1
480
TimeTree の SRE が海外展開においてやったこと&やってないこと by【TimeTree × みてね勉強会】 グローバル対応への挑戦 〜SRE/インフラ編〜
ekanai
June 09, 2023
Tweet
Share
More Decks by ekanai
See All by ekanai
TimeTree のデータベースを Aurora から Cloud Spanner へ移行
3utama
1
210
[TimeTree] Aurora から Spanner への 移行の決断と背景
3utama
2
3.7k
数十億レコードのRDS MySQL5.6を1週間程でAurora MySQL5.7へ移行した時の話 #jawsdays
3utama
0
3.5k
1日でSSHをやめることができた話 #jawsdays
3utama
10
17k
Other Decks in Technology
See All in Technology
Platform Engineeringで クラウドの「楽しくない」を解消しよう
jacopen
4
210
エンジニアのキャリアパスと、 その中で自分が大切にしていること
noteinc
3
310
JAWS FESTA 2024「バスロケ」GPS×サーバーレスの開発と運用の舞台裏/jawsfesta2024-bus-gps-serverless
ma2shita
3
370
OPENLOGI Company Profile
hr01
0
60k
Pwned Labsのすゝめ
ken5scal
2
570
Cracking the Coding Interview 6th Edition
gdplabs
14
28k
事業を差別化する技術を生み出す技術
pyama86
2
540
ライフステージの変化を乗り越える 探索型のキャリア選択
tenshoku_draft
1
120
Amazon Aurora のバージョンアップ手法について
smt7174
2
190
AWSアカウントのセキュリティ自動化、どこまで進める? 最適な設計と実践ポイント
yuobayashi
7
1.8k
AWSではじめる Web APIテスト実践ガイド / A practical guide to testing Web APIs on AWS
yokawasa
8
790
大規模アジャイルフレームワークから学ぶエンジニアマネジメントの本質
staka121
PRO
3
1.7k
Featured
See All Featured
Music & Morning Musume
bryan
46
6.4k
Git: the NoSQL Database
bkeepers
PRO
428
65k
Product Roadmaps are Hard
iamctodd
PRO
51
11k
Building Applications with DynamoDB
mza
93
6.2k
YesSQL, Process and Tooling at Scale
rocio
172
14k
GraphQLの誤解/rethinking-graphql
sonatard
69
10k
Designing Experiences People Love
moore
140
23k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
Why You Should Never Use an ORM
jnunemaker
PRO
55
9.2k
A Tale of Four Properties
chriscoyier
158
23k
Code Reviewing Like a Champion
maltzj
521
39k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
33
2.8k
Transcript
TimeTree の SRE が 海外展開において やったこと&やってないこと
TimeTree の紹介 予定をつくって、共有してコミュニケー ションできるアプリです TimeTreeは、予定の共有と相談が驚くほど 簡単にできるコミュニケーションアプリです。 カレンダーひとつで、決まった予定の共有 も、これからの楽しみな予定の相談も簡単 にできます。
自己紹介 名前:金井 栄喜(カナイ エイキ) 所属:株式会社TimeTree 役割: SRE チームリード ニックネーム: miu
趣味:ラーメン作り, DIY 家族構成:妻と猫2匹と私
目次 - やったこと - やってないこと
やったこと
やったこと - ネットワークパフォーマンス改善 - セキュリティ
やったこと - ネットワークパフォーマンス改善 - セキュリティ
ネットワークパフォーマンス改善 解決したい問題 - 物理的な距離があるほど通信する距離が増加する - 単純にネットワーク時間が増加する - 離れている海外のユーザーほど影響がある - 海外ユーザーのボリュームゾーンは結構離れている
ネットワークパフォーマンス改善 - CloudFront を利用した改善 - BackendAPI 改善
ネットワークパフォーマンス改善 - CloudFront を利用した改善 - BackendAPI 改善
ネットワークパフォーマンス改善 CloudFront を利用したネットワークパフォーマンスの改善 どうやって解決するか - CloudFront を利用することで AWS で最適化されたネットワークを利用できる -
ユーザーにより近いエッジロケーションから最適化されたネットワークを利用す ることでパフォーマンスの向上をはかる
ネットワークパフォーマンス改善 CloudFront を利用したネットワークパフォーマンスの改善 CloudFront とは - Amazon Web Services(AWS)が提供するグローバルなコンテンツ配信ネット ワーク(CDN)サービス
- AWS ネットワークバックボーンを介して AWS リージョンに接続 - 450 以上の Point of Presence のグローバルネットワークと 48 か国の 90 以上 の都市にある 13 のリージョンレベルのエッジキャッシュ
ネットワークパフォーマンス改善 CloudFront を利用したネットワークパフォーマンスの改善 参照元 https://aws.amazon.com/jp/cloudfront/features/?whats-new-cloudfront.sort-by=item.addi tionalFields.postDateTime&whats-new-cloudfront.sort-order=desc
ネットワークパフォーマンス改善 CloudFront を利用したネットワークパフォーマンスの改善 AWS ネットワークバックボーンを介して AWS リージョンに接続 - エッジロケーションからサーバーまで AWS
で最適化されたネットワークを利用し て通信することが可能 - -> CloudFront を利用しないグローバルなインターネットからなアクセスよりも ネットワークパフォーマンスの改善が見込まれる
ネットワークパフォーマンス改善 CloudFront を利用したネットワークパフォーマンスの改善 対応内容 - インフラ構成変更 - メインの対応 - クライアント
IP 取得方法変更 - メインの対応をした際にアプリケーションに影響を与えないための対応
ネットワークパフォーマンス改善 CloudFront を利用したネットワークパフォーマンスの改善 インフラ構成変更 変更前 変更後
ネットワークパフォーマンス改善 CloudFront を利用したネットワークパフォーマンスの改善 クライアント IP 取得方法変更 - アプリケーションのログとしてクライアント IP が必要
- IP 自体は機密情報としてセキュリティ対策はバッチリです - 今までは LB -> Fargate だった - 変更後は CloudFront -> LB -> Fargate になるため Fargate に到達するまでの 経路が増えた - 多段での IP 取得方法に変更する必要がある
ネットワークパフォーマンス改善 - CloudFront を利用した改善 - BackendAPI 改善
ネットワークパフォーマンス改善 Backend API 改善 どうやって解決するか - 呼び出し回数の最適化 - 一覧系の API
の取得件数の最適化 - API 呼び出し回数が減らせる可能性 -> 遠隔地からのネットワーク時間の短縮 - 動的 API をキャッシュできるように変更 - CloudFront でキャッシュする - API 結果がエッジロケーションから返却されることでネットワーク時間の短縮 - あわよくばサーバーの負荷軽減
ネットワークパフォーマンス改善 Backend API 改善 どうやって解決するか - 呼び出し回数の最適化 - 一覧系の API
の取得件数の最適化 - API 呼び出し回数が減らせる可能性 -> 遠隔地からのネットワーク時間の短縮 - 動的 API をキャッシュできるように変更 - CloudFront でキャッシュする - API 結果がエッジロケーションから返却されることでネットワーク時間の短縮 - あわよくばサーバーの負荷軽減
ネットワークパフォーマンス改善 Backend API 改善 (呼び出し回数の最適化) 対応内容 - 一覧 API の取得件数の増加
- クライアントサイドでの修正が必要かどうか Frontend チームと相談 - 取得件数を変更(例 100 件 -> 200 件) - APM で API の遅延具合を確認 - SQL の見直し
ネットワークパフォーマンス改善 Backend API 改善 どうやって解決するか - 呼び出し回数の最適化 - 一覧系の API
の取得件数の最適化 - API 呼び出し回数が減らせる可能性 -> 遠隔地からのネットワーク時間の短縮 - 動的 API をキャッシュできるように変更 - CloudFront でキャッシュする - API 結果がエッジロケーションから返却されることでネットワーク時間の短縮 - あわよくばサーバーの負荷軽減
ネットワークパフォーマンス改善 Backend API 改善 (動的エンドポイントをキャッシュできるように変更) 対応内容 - Backend API アプリケーションを変更
- CloudFront にキャッシュの設定を追加
ネットワークパフォーマンス改善 Backend API 改善 (動的エンドポイントをキャッシュできるように変更) 対応内容(Backend API アプリケーションを変更) - キャッシュに適したリクエストパラメータ設計&実装
ネットワークパフォーマンス改善 Backend API 改善 (動的エンドポイントをキャッシュできるように変更) 気を付けること(Backend API アプリケーションを変更) - 動的
API をキャッシュする - 機密情報が含まれている可能性 - セッション情報など - 十分に設計やテストを実施した上で移行していく
ネットワークパフォーマンス改善 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
ネットワークパフォーマンス改善 Backend API 改善 (動的エンドポイントをキャッシュできるように変更) 気を付けること(CloudFront の設定変更) - Behavior の優先順位
- キャッシュキー
ネットワークパフォーマンス改善 なぜこのような対応を実施したか - コスパがよい - CFRC(CloudFront Reserved Capacity) の検討時期でもあったためタイミング的 にちょうどよかった
- 対応後の運用コストにもほぼ影響なし
ネットワークパフォーマンス改善 結果 - クライアントの APM 未導入なので具体的な数値はわからず - パフォーマンスに関する海外からのお問い合わせはなし
ネットワークパフォーマンス改善 気にしたいこと - CloudFront の料金 - サービス開始時は問題ないと思う - スケールしてきてリクエスト数が増加してくると思いのほか料金がかかる可能性 -
AWS の担当の方とよく相談をして対応していくと解消しやすいです
やったこと - ネットワークパフォーマンス改善 - セキュリティ
セキュリティ 解決したい問題 - ユーザーの不安を少しでも解消する - 日本とは異なる法律への準拠
セキュリティ - 基本的な部分の見直し - GDPR
セキュリティ - 基本的な部分の見直し - GDPR
セキュリティ 基本的な部分の見直し どうやって解決するか - 暗号化やネットワーク構成などの見直し - S3 やデータベースなど暗号化がされているか - インターネットから進入可能な環境はないか
- セキュリティ関連対応状況がすぐに確認できる環境 - AWS Security Hub の導入 - 心配になったユーザーのお問合せに即座に誰でも対応 - 会社の機密情報保持状況について部分的な確証
セキュリティ 基本的な部分の見直し 対応内容 - AWS Security Hub 導入 - AWS
リソースがルールから外れていないか自動でチェック - IaC リファクタリング - より迅速に対応できるように - SCP 作成 - ガードレールでリスク回避 - パブリックネットワーク環境廃止
セキュリティ 基本的な部分の見直し Security Hub はこんな見た目(一部)
セキュリティ - 基本的な部分の見直し - GDPR
セキュリティ GDPR どうやって解決するか - とにかくやらなくてはならないことの洗い出しと対応(以下抜粋) - ユーザー所有と見なされるデータの範囲 - データ -
ログ - 画像 etc - ユーザーが所有するデータのダウンロード - 解約したユーザーデータの保持期間 - etc
セキュリティ GDPR 対応内容 - データダウンロード用環境を用意 - S3 - ダウンロード機能実装 -
問い合わせベースでのダウンロード機能 - データ保持期間の徹底 - S3 ライフサイクル - 解約後のデータ削除機能 - バッチ処理作成
セキュリティ なぜこのような対応を実施したか - やらなくてはならない部分 - ユーザーからの信頼性 - 海外ユーザーの方が日本ユーザーよりもセキュリティ状況に敏感な傾向 - バウンティハンター
- とても大事なことでありサービスのグロースと良いタイミングだった
セキュリティ おまけ - 中国に本格参入するか?みたいな話が内輪で上がったことも - 中国サイバーセキュリティー法 - Android 参入の難易度 -
中国以外のデータとの住み分け - etc - この時は無理そうだねと立ち消えしました
やってないこと
やってないこと - マルチリージョン対応 - クライアントモニタリング
なぜやっていないのか - 全体を通して - 会社における海外展開の重要度 - 基本的な構成や運用のリファクタリングを優先 やってないこと
なぜやっていないのか (マルチリージョン) - データ量の増加へのアプローチ - まずはシャーディング - 人的リソース - 対応後の運用含め一人でできるのか
- データベース同期ラグを考慮した改修 - より優先度の高い改善や新規機能 - 会社として優先度がそこまで高くない状況でのみんなを巻き込んだ開発 やってないこと
なぜやっていないのか (クライアントモニタリング) - 費用 - ちょっと試しにやってみたけどかなりのデータ量に - 工夫が必要 - 一歩踏み込めなかった甘さ
- バックエンドは APM を利用した分散トレーシングを導入していてちょっと満足していた - クライアントは GA でなんとなくモニタリングしていた - いざ試しに導入してみると色々問題もありもっと早く動いていれば状況は変わっていたかも やってないこと
まとめ
- できることとできないことが存在する - 人やお金の問題 - 会社が求めるもの - まずは色々考えてみることが大切 - 考えないと始まらない
- 海外のユーザーはどう感じているか想像してみる - 本当にやった方がいいと思うことは会社全体を巻き込んで - 会社の状況を見てリソース的にいけそうな雰囲気など判断して声を上げてみる - 社内に落ちている色々なデータなど利用したり - すぐにできてしまうことはやっちゃうのもあり - チームや自分の責任範囲ですぐにできてしまうものなどは積極的に導入してしまう - 納得や効果が得られなければロールバックすれば良い まとめ
宣伝
採用イベント開催予定です! - 6月21日 ビジネスDiv https://bit.ly/3qx10kZ - 6月27日 プロダクトDiv https://bit.ly/42xTV1e - 7月4日 エンジニア(Tech
Talk) https://bit.ly/3oNrK0m 宣伝
ありがとうございました 連絡先: 会社名 株式会社TimeTree (TimeTree, Inc.) 郵便番号 160-0023 東京都新宿区西新宿 6丁目6-3
新 宿国際ビルディング 新館 503 miu@timetreeapp.com https://timetreeapp.com/intl/ja/ corporate