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
転職会議サービスのAWS移行記録
Search
na-o-ys
March 10, 2017
0
61
転職会議サービスのAWS移行記録
na-o-ys
March 10, 2017
Tweet
Share
More Decks by na-o-ys
See All by na-o-ys
IoTと監視
naoys
1
770
RubyとJIT
naoys
0
160
将棋盤を画像認識したかった
naoys
0
1.5k
Rust で乗り換え案内
naoys
0
620
疎行列と Jaccard 類似度の高速計算
naoys
1
610
有理数集合の濃度
naoys
2
120
YARVの最適化について調べた
naoys
0
130
Anonymous Recursion in C++
naoys
0
420
入門AlphaGo
naoys
5
3.8k
Featured
See All Featured
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
34
5.9k
Code Reviewing Like a Champion
maltzj
524
40k
Being A Developer After 40
akosma
90
590k
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
48
5.4k
Speed Design
sergeychernyshev
32
1k
Bash Introduction
62gerente
614
210k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
32
2.3k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
45
7.5k
Adopting Sorbet at Scale
ufuk
77
9.4k
Build The Right Thing And Hit Your Dates
maggiecrowley
36
2.8k
Side Projects
sachag
455
42k
Transcript
転職会議サー ビスの AWS 移行記録 株式会社リブセンス 転職会議プラットフォー ムチー ムリー ダー 岡前
直由 @na_o_ys
転職会議サー ビス群を AWS に移行した話
いままでの転職会議 マイクロサー ビス化 システムの境界 = 責任の境界 単一オンプレ DB への依存 バッチの
lambda 化とか SQS の利用とかが難しい サー バー 構築依頼などの社内調整コスト スピー ドの制約
なぜ移行したのか マネー ジドサー ビス利用の促進、 設計選択肢を増やしたい 開発スピー ドの向上 事業的に投資可能なタイミングが来た
移行方式: 一括移行 ※ E last ic S ear ch など一部の低依存サー
ビスは先行移行
プロジェクト 人数: 5人 着工: 2016/9 移行日: 2017/3/15 (がんばります!)
本日のトピック (試行錯誤の末の) AWS 活用方法をご紹介 マルチアカウントでの IAM 管理 CI / CD
ハマりどころ
マルチアカウントでの IAM 管理 pr odu ct ion (本番) / dev
(ステー ジング) の 2 AWS アカウント 開発者ユー ザは dev に作成 sw it ch r ole で pr odu ct ion 上の r ole に昇格 admin グルー プと dev elop er グルー プ
マルチアカウントの利点 本番系とステー ジング系で同一の構成を目指せる チャレンジングな検証を dev で行える pr odu ct ion
でのオペミスの心配を減らせる
CI /CD ビルド (G itH u b ‑ C ir
cle CI ‑ S 3) デプロイ (chat bot ‑ C ode D ep loy ‑ EC 2)
このフロー の利点 デプロイタイミングを制御できる 特定ブランチのデプロイなどが自由にできる
ハマりどころ AWS 周りでのハマりどころはそんなに無かった 大変なのは、 現行システムの全貌や外部連携の把握… あえて挙げるなら レガシー バッチから DB への大量アクセスが捌けなかった
DB へのアクセス速度が足りない 課題 あるバッチ: 秒間 2000 ins ert * 2
時間 素直に RDS 利用すると: 10 時間かかるように… 対策 (1) アプリケー ションと RDS の A Z を揃える (2) innodb_flus h_log_at_trx_commit=0 ※ 結果 秒間 2000 wr it e 達成ヽ(=´▽ `=)ノ ※ innodb のログファイルのディスク書き込みのフラッシュタイミングを緩くする
まとめ 移行プロジェクトの労力の大半は、 現行仕様の把握と AWS の運用 設計 (の試行錯誤) A Z またぎの通信が遅いなどのハマりどころはある