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
AWSではじめる Web APIテスト実践ガイド / A practical guide to testing Web APIs on AWS
yokawasa
8
750
フォーイット_エンジニア向け会社紹介資料_Forit_Company_Profile.pdf
forit_tech
1
1.7k
Amazon Aurora のバージョンアップ手法について
smt7174
2
180
ウォンテッドリーのデータパイプラインを支える ETL のための analytics, rds-exporter / analytics, rds-exporter for ETL to support Wantedly's data pipeline
unblee
0
140
技術スタックだけじゃない、業務ドメイン知識のオンボーディングも同じくらいの量が必要な話
niftycorp
PRO
0
120
4th place solution Eedi - Mining Misconceptions in Mathematics
rist
0
150
What's new in Go 1.24?
ciarana
1
110
データベースの負荷を紐解く/untangle-the-database-load
emiki
2
540
【内製開発Summit 2025】イオンスマートテクノロジーの内製化組織の作り方/In-house-development-summit-AST
aeonpeople
2
1.1k
クラウド関連のインシデントケースを収集して見えてきたもの
lhazy
9
1.8k
【詳説】コンテンツ配信 システムの複数機能 基盤への拡張
hatena
0
280
クラウド食堂とは?
hiyanger
0
120
Featured
See All Featured
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
29
1k
Speed Design
sergeychernyshev
27
810
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
21
2.5k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
13
1k
Reflections from 52 weeks, 52 projects
jeffersonlam
348
20k
Six Lessons from altMBA
skipperchong
27
3.6k
The Pragmatic Product Professional
lauravandoore
32
6.4k
Rails Girls Zürich Keynote
gr2m
94
13k
Stop Working from a Prison Cell
hatefulcrawdad
268
20k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
129
19k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
33
2.8k
Making Projects Easy
brettharned
116
6k
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
[email protected]
https://timetreeapp.com/intl/ja/ corporate