サーバー移行時のざっくりとした手順と考えるべきこと
ちょっとした記憶の整理。
2016年の10月くらいから2ヶ月間かけて事業の全サーバーをGMOクラウドからAWSへサーバーを移行したのでそのときの手順。本当は終わった直後に書けば記憶が鮮明なので詳細に書けたのに・・・それを言っても仕方ないのでとりあえず思い出せるだけ思い出します。
と話に入るまえにこういった大きなことをするときのポイントを述べておきます。それは
既存の環境(GMOクラウドの環境)をなるべくそのまま新規の環境へ（AWS）へ移す
これ結構大事です！移行しようとして色々調べたりすると「あれ？これいらなくね？」とか「え？これこのバージョンなの？あげたほうがよくね？」といったものが結構多く出てきます。しかしここはぐっとこらえて一旦、目を閉じましょう。もしリファクタリングみたいなことを同時にしてしまうとエラーになったときに、問題の原因特定が極めて困難になります。
ちなみに僕はアプリケーション側のサーバー設定のときに設定ファイル含めリファクタリングしながらやってしまい、結構困りました。エラーになったとき「新規のサーバーの設定ミスなのか？それともリファクタリングしたときのミスなのか？」と原因推測の範囲が分散してしまいわけわからなくなりました。もしこれをリファクタリングしないで進めていたとすると、既存の環境では動いていたのは事実なのでサーバーの設定ミスっぽいなと、ある程度明確に当たりをつけられます。もし古いものを新しくするときはこのことを覚えておくと結構早く物事を進められるかもしれません。
話を戻して以下が手順です。
- 既存のネットワーク、サーバー構成の確認
新規で0→1のサービスを作るならこんなこと考えなくて調べて洗い出してみたいなことをやらなくていいし、やるとしてもおそらく今だとgithubとかでどういう設計にしたのかを残しておくと思うのですが。。うちの事業は10年くらい前からやっていてそのときの記録が一切ないので現状を把握することから始めました。
- 既存で使われているライブラリやツールの確認
うちはnginx→unicornでサーバーが構成されていました。各々のサーバーでどんなミドルウェアが使われいるのかを確認します。
＊＊ここまでが現状の理解になります＊＊
- 新規のネットワーク・サーバー構成の考案
ここは全体設計の話なのでかなり楽しかった記憶があります笑。サーバーの移行なんてそうそう行うものではないので「自分の考えた構成が残っていくのかぁぁぁ」と深く感動したものです。ただこの頃インフラなんて触ったことなかったので設計と言われてもなにがなんだか・・という感じでした。
なのでキャッチアップしながら進めました。以下が流れです。
１：とりあえず「サーバー移行」と適当にググったりインフラの本読んだりする。
Amazon Web Services 基礎からのネットワーク&サーバー構築
- 作者: 玉川憲,片山暁雄,今井雄太
- 出版社/メーカー: 日経BP社
- 発売日: 2014/07/16
- メディア: 単行本
- この商品を含むブログ (4件) を見る
２：それらを見て・読んでなんとなくの全体像を把握。名前すら知らなかったのもあったのでここでは本当に「こんな感じなのかー」という感覚をつかむ程度。
３：（自分の環境を作ってまずは遊んでみるのもあり）
４：設計の本を読んだり、他社さんのを参考にしたりする。以下を読みましたね。あとはAWSのブログとか見てたような気がします。
Amazon Web Services パターン別構築・運用ガイド
- 作者: NRIネットコム株式会社,佐々木拓郎,林晋一郎,小西秀和,佐藤瞬
- 出版社/メーカー: SBクリエイティブ
- 発売日: 2015/03/25
- メディア: 単行本
- この商品を含むブログ (2件) を見る
Amazon Web Servicesクラウドデザインパターン設計ガイド 改訂版（日経BP Next ICT選書）
- 作者: 玉川憲,片山暁雄,鈴木宏康,野上忍,瀬戸島敏宏,坂西隆之
- 出版社/メーカー: 日経BP社
- 発売日: 2015/07/21
- メディア: Kindle版
- この商品を含むブログを見る
５：4まででなんとなく設計に必要そうな技術がわかるのでとりあえずそれらを知っておく、また似たようなことができるのもあるのでそれらの違いを理解する。僕の中では「elastic beanstalk / opsworks / cloudformation」の違いがよくわからなかったのでそれを結構調べましたww
６：以上のことを踏まえて設計を考える。真似でも良いと思います。その候補が上がったら、各々の候補同士でメリットデメリットを考える
７：デメリットを考えるときは「一番最悪のことが起こったときどう対処できるのか」という基準を持つとすっきりします。
全体の話に戻します。この先は言わずもがなですね。
- 実際に構築
実際に作る前に部分部分で小さく作って問題ないのかの検証して、できなさそうならもう一度考えて作って検証するというのの繰り返しをやって「できる！」となった時点で実際の全体構築に入りました。
- 全体のテスト
アクセステストやらDBがちゃんと動いているのかといったテストをしました。
- 本番環境にする
というのが僕がやった時の流れです。実際に作るときには、「これできるのか？」みたいな検証に時間がかかってたような気がします。そんな時はAWSのサポートに問い合わせてみると答えが返ってくるかもしれません。最終こんな感じになりました。
こだわったポイントは以下ですかね笑
・この図だとわかりませんがcapistrano deployからblue green deploy方式に変えた
・この図だとわからないかもしれませんが、セキュリティ面強化のためにweb機をpublicにapplication機をprivateにおいた
・AMIを主体にcloudformaiton一発でこの環境ができるようにした
最後に・・・・
最近は、そろそろGCPを触る時が来たかなと思っているのでAWSからGCPに移行してみたというのもやってみようと思っています。
終わり。
