転職会議サービスのAWS移行記録

Transcript

1. 転職会議サー ビスの AWS 移行記録 株式会社リブセンス 転職会議プラットフォー ムチー ムリー ダー 岡前 直由 @na_o_ys
2. 転職会議サー ビス群を AWS に移行した話
3. いままでの転職会議 マイクロサー ビス化 システムの境界 = 責任の境界 単一オンプレ DB への依存 バッチの lambda 化とか SQS の利用とかが難しい サー バー 構築依頼などの社内調整コスト スピー ドの制約
4. なぜ移行したのか マネー ジドサー ビス利用の促進、 設計選択肢を増やしたい 開発スピー ドの向上 事業的に投資可能なタイミングが来た
5. 移行方式: 一括移行 ※ E last ic S ear ch など一部の低依存サー ビスは先行移行
6. プロジェクト 人数: 5人 着工: 2016/9 移行日: 2017/3/15 (がんばります!)
7. 本日のトピック (試行錯誤の末の) AWS 活用方法をご紹介 マルチアカウントでの IAM 管理 CI / CD ハマりどころ
8. マルチアカウントでの IAM 管理 pr odu ct ion (本番) / dev (ステー ジング) の 2 AWS アカウント 開発者ユー ザは dev に作成 sw it ch r ole で pr odu ct ion 上の r ole に昇格 admin グルー プと dev elop er グルー プ
9. マルチアカウントの利点 本番系とステー ジング系で同一の構成を目指せる チャレンジングな検証を dev で行える pr odu ct ion でのオペミスの心配を減らせる
10. CI /CD ビルド (G itH u b ‑ C ir cle CI ‑ S 3) デプロイ (chat bot ‑ C ode D ep loy ‑ EC 2)
11. このフロー の利点 デプロイタイミングを制御できる 特定ブランチのデプロイなどが自由にできる
12. ハマりどころ AWS 周りでのハマりどころはそんなに無かった 大変なのは、 現行システムの全貌や外部連携の把握… あえて挙げるなら レガシー バッチから DB への大量アクセスが捌けなかった
13. 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 のログファイルのディスク書き込みのフラッシュタイミングを緩くする
14. まとめ 移行プロジェクトの労力の大半は、 現行仕様の把握と AWS の運用 設計 (の試行錯誤) A Z またぎの通信が遅いなどのハマりどころはある