オンプレからクラウドへ移行するための頑張らないアーキテクチャ

吉祥寺.pm37
LT枠

https://kichijojipm.connpass.com/event/339040/

Transcript

1. オンプレからクラウドへ移行するた めの頑張らないアーキテクチャ @yabakokobayashi 1
2. 自己紹介 小林将太(@yabakobayashi) ▪ アフィリエイトのシステム全般開発 ▪ オンプレとクラウドをいったりきたり ▪ PHPとGoをいったりきたり 2
3. クラウド移行で障害なる要因は何があるか？ 3
4. 1. 現行システムの理解 2. コストの見積もり 3. データ移行 4. セキュリティとコンプライアンス 5. 非互換性 6. クラウドネイティブな設計の適応 7. 運用体制 4
5. 1. 現行システムの理解 2. コストの見積もり 3. データ移行 4. セキュリティとコンプライアンス 5. 非互換性 6. クラウドネイティブな設計の適応 7. 運用体制 5
6. 社内セキュリティへの 適合 マネージドDBのコスト ダウンタイムなどの考慮 そもそも売上に直結しないの で優先度低い・・・ 6
7. オンプレのままでもいいか ... 7
8. りょ (クラウド移行は後回しやな) あれもこれもやってね 前まで 8
9. (インフラ老朽化や、各システムの構成を拡 張したりで手一杯) (なんか開発遅いような ) 数年後 9
10. せめてkubernetes環境を作る？ オンプレで・・・ 経験もなしに大規模を・・・・・・　無理！！ いまから勉強して！？ 出来る！？ 否 死 10
11. クラウド移行に向き合わなきゃ 11
12. 12 オンプレDBどうしよう・・・ Cloud Interconnect使えるようになりました ※オンプレとGoogle ネットワークの間の物理的な直接接続してくれるすごいやつ！
13. それなら(頑張らず)いける 13
14. 移行対象を考える アプリケーション データベース バッチ そもそもこいつら全部をクラウド化しようとするからややこしくなる 14
15. 頑張って移行するところ /しないところ 1. 頑張って移行 a. 負荷が大きく変動し、スケーラビリティが重要なもの i. ユーザ画面、キャンペーン b. 負荷が集中する時間が決まっているもの i. 定期的なバッチ処理 2. 頑張ると辛いので今回は見送り a. 実行時間が長いもの i. 大量のデータ分析処理 b. 複雑性が高いもの i. 実行に順序性がある処理、データベース c. エンドユーザが参照しないもの i. 社内管理画面 15
16. Cloud Load Balancing • パスルールでオンプレとクラウドを振り分け • オンプレでIP制限している場合は、GCPのIPを許可する 必要あり 16
17. 移行はDNSで切り替えるだけなので難しいことは一切なし！ 17
18. 工数や影響を考慮して段階的なリプレイスを採用 • ユーザーの画面を対象 ◦ 全ての画面を一気にリプレイスせず、変更後の 影響範囲を狭める • フロントとバックエンドは分離 ◦ 既存は密結合している ◦ 規模やを鑑みると、分離してスケーラビリティや 変更影響を限定的にしたい • DBはオンプレミスをそのまま使用 ◦ 個人情報が保存されており、クラウド移行に大 きな課題がある 18
19. クラウド移行してみて 1. 急な負荷によるサーバ保守対応が少なくなった a. バッチが止まってたりね ... 2. モニタリングが改善された a. オンプレ時は各サーバの構築時期によって整理されてなかった 3. 移行による障害が起きても部分的だったので、致命傷ですんだ 4. コストは安くなった部分と高くなった部分がある a. アプリケーション実行環境はサーバレスになって安くなった b. 通信が鬼高い i. 特にオンプレとの通信につかっている Dedicated Interconnect DBも移行すればい いのに・・・ 19
20. オンプレの　重さ感じて　雲恋し 20
21. ありがとうございました 21