読者です 読者をやめる 読者になる 読者になる

katsuyukikun’s diary

とある天パーエンジニアのblog

サーバー移行時のざっくりとした手順と考えるべきこと

ちょっとした記憶の整理。

2016年の10月くらいから2ヶ月間かけて事業の全サーバーをGMOクラウドからAWSへサーバーを移行したのでそのときの手順。本当は終わった直後に書けば記憶が鮮明なので詳細に書けたのに・・・それを言っても仕方ないのでとりあえず思い出せるだけ思い出します。

 

f:id:katsuyukikun:20170317012524p:plain

 

と話に入るまえにこういった大きなことをするときのポイントを述べておきます。それは

既存の環境(GMOクラウドの環境)をなるべくそのまま新規の環境へ(AWS)へ移す

 

これ結構大事です!移行しようとして色々調べたりすると「あれ?これいらなくね?」とか「え?これこのバージョンなの?あげたほうがよくね?」といったものが結構多く出てきます。しかしここはぐっとこらえて一旦、目を閉じましょう。もしリファクタリングみたいなことを同時にしてしまうとエラーになったときに、問題の原因特定が極めて困難になります。

ちなみに僕はアプリケーション側のサーバー設定のときに設定ファイル含めリファクタリングしながらやってしまい、結構困りました。エラーになったとき「新規のサーバーの設定ミスなのか?それともリファクタリングしたときのミスなのか?」と原因推測の範囲が分散してしまいわけわからなくなりました。もしこれをリファクタリングしないで進めていたとすると、既存の環境では動いていたのは事実なのでサーバーの設定ミスっぽいなと、ある程度明確に当たりをつけられます。もし古いものを新しくするときはこのことを覚えておくと結構早く物事を進められるかもしれません。

 

 

話を戻して以下が手順です。

  • 既存のネットワーク、サーバー構成の確認

新規で0→1のサービスを作るならこんなこと考えなくて調べて洗い出してみたいなことをやらなくていいし、やるとしてもおそらく今だとgithubとかでどういう設計にしたのかを残しておくと思うのですが。。うちの事業は10年くらい前からやっていてそのときの記録が一切ないので現状を把握することから始めました。

 

  • 既存で使われているライブラリやツールの確認

うちはnginx→unicornでサーバーが構成されていました。各々のサーバーでどんなミドルウェアが使われいるのかを確認します。

 **ここまでが現状の理解になります**

  • 新規のネットワーク・サーバー構成の考案

ここは全体設計の話なのでかなり楽しかった記憶があります笑。サーバーの移行なんてそうそう行うものではないので「自分の考えた構成が残っていくのかぁぁぁ」と深く感動したものです。ただこの頃インフラなんて触ったことなかったので設計と言われてもなにがなんだか・・という感じでした。

なのでキャッチアップしながら進めました。以下が流れです。

1:とりあえず「サーバー移行」と適当にググったりインフラの本読んだりする。

Amazon Web Services 基礎からのネットワーク&サーバー構築

Amazon Web Services 基礎からのネットワーク&サーバー構築

 

 

2:それらを見て・読んでなんとなくの全体像を把握。名前すら知らなかったのもあったのでここでは本当に「こんな感じなのかー」という感覚をつかむ程度。 

3:(自分の環境を作ってまずは遊んでみるのもあり)

4:設計の本を読んだり、他社さんのを参考にしたりする。以下を読みましたね。あとはAWSのブログとか見てたような気がします。

 

Amazon Web Services パターン別構築・運用ガイド

Amazon Web Services パターン別構築・運用ガイド

 

 

Amazon Web Servicesクラウドデザインパターン設計ガイド 改訂版(日経BP Next ICT選書)

Amazon Web Servicesクラウドデザインパターン設計ガイド 改訂版(日経BP Next ICT選書)

 

 

aws.typepad.com

 

5:4まででなんとなく設計に必要そうな技術がわかるのでとりあえずそれらを知っておく、また似たようなことができるのもあるのでそれらの違いを理解する。僕の中では「elastic beanstalk / opsworks / cloudformation」の違いがよくわからなかったのでそれを結構調べましたww

6:以上のことを踏まえて設計を考える。真似でも良いと思います。その候補が上がったら、各々の候補同士でメリットデメリットを考える

7:デメリットを考えるときは「一番最悪のことが起こったときどう対処できるのか」という基準を持つとすっきりします。

 

全体の話に戻します。この先は言わずもがなですね。

  • 実際に構築

実際に作る前に部分部分で小さく作って問題ないのかの検証して、できなさそうならもう一度考えて作って検証するというのの繰り返しをやって「できる!」となった時点で実際の全体構築に入りました。

  • 全体のテスト

アクセステストやらDBがちゃんと動いているのかといったテストをしました。

  • 本番環境にする

 

というのが僕がやった時の流れです。実際に作るときには、「これできるのか?」みたいな検証に時間がかかってたような気がします。そんな時はAWSのサポートに問い合わせてみると答えが返ってくるかもしれません。最終こんな感じになりました。

 

f:id:katsuyukikun:20170317212708p:plain

 

 

こだわったポイントは以下ですかね笑

・この図だとわかりませんがcapistrano deployからblue green deploy方式に変えた

・この図だとわからないかもしれませんが、セキュリティ面強化のためにweb機をpublicにapplication機をprivateにおいた

・AMIを主体にcloudformaiton一発でこの環境ができるようにした

 

 

 

 

最後に・・・・

最近は、そろそろGCPを触る時が来たかなと思っているのでAWSからGCPに移行してみたというのもやってみようと思っています。

 

www.publickey1.jp

 

 

終わり。

 

DroidKaigiに初めて参加してみた

初めてブログを書きます!

技術系の話の定期的なアウトプットの場としてやっていこうかなと思います。qiitaでも良かったんですが、読んだ本のアウトプットとかだとちょっと場違い感があるので、こちらで気ままにやっていきます。

 

今回は第一回ということで何を書いて良いかわからないのでとりあえず最近行ってきたイベント、、、3月9日、10日とベルサール新宿グランドで開かれたDroidKaigi 2017について、今年初参加なのでその感想を軽く書こうかなと思います。

 

droidkaigi.github.io

 

そもそもDroidKaigiってなんなのかというと、Android技術情報の共有とコミュニケーションを目的の場です。ちなみに2015年から毎年開催されているカンファレンスで2017年は第3回目です。動員数800名、セッション数も2日間で67。スポンサーは30社と結構大きいイベントっぽいです。

 

【全体の感想】

そもそも僕はandroid開発経験ゼロ・・最近趣味でチュートリアルっぽいのをいじってるくらいのレベル、しかもカンファレンスというもの自体今回が初めてです笑。

そんな僕ですら、かなり良い勉強になりました!2日間で8000円でしたが払う価値は十分あるなといった所感です。(ご飯も美味しいし、お菓子も食べ放題wwマフィンみたいなやつがめちゃ美味しくてずっと食べてました笑)

 

【セッションの感想】

タイムスケジュールにはセッションの概要が載っています。そこにレベル感(初級〜中級といったもの)が書いてあり、自分のレベルに合わせて聞きに行けます。また今回がたまたまだったのかよくわからないですが、僕レベルでもわかるような、興味を持てるような内容が多かった印象ですね。あと全体設計の話、ドメイン駆動設計(DDD)の話はどこでもしてたなといった印象ですかね。マイクロアーキテクチャというワードも流行ってるしこの辺の流れなのかな・・・

個人的に印象に残っているのは以下2つ。

 

speakerdeck.com

 

 

speakerdeck.com

 

⬛︎ 大規模アプリのリノベーション

はてなブックマークアプリのリファクタリングについてのお話です。リファクタリングはまとまった時間を取らないと、それ自体が負の遺産になっちゃうよねという話から始まり具体的にどう進めていったのかというのが詳細にわかります。何年も行ってきているサービスに携わっている人なら非常に共感でき、学べることも多い内容だと思います。

 

⬛︎ androidアプリ開発の体力づくり

メルカリ→ソウゾウでandroidアプリ開発を行ってきた人が初心者向けに行ってくれたセッションです。「なんかアプリ作りたいけどアイデアねーよ」とか「技術以上にデザインの部分で詰まって困るよねー」といったアプリを初めて作る人が抱きそうな感情の共感から話が始まり、どういうマインドで作っていくべきなのか、また最新の技術はどうキャッチアップしながらやっていくのか、アップデートのタイミングはどうするのかといった内容でした!とりあえず頑張ってやってみようという気持ちになりましたwww

 

【会場の雰囲気】

セッションごとに自分で聞きたい部屋に行く、、大学の講義を思い出しました笑。会場自体はわりかしフランクな雰囲気だったかなと思います。

今回は、お菓子食べ放題コーナーと企業ブースが同じ部屋にありました。僕はマフィンを食べに毎回その部屋に入っていたのですがかなり賑わっていました。また企業側の方もフランクに話しかけてくださります。「今回初参戦なんですよね、しかもandroid開発も最近始めたばかりで・・」と言うと技術のこと含め色々教えてくれたりしました笑。そんなのもこう言ったカンファレンスだからこそ楽しめるのかもしれません。

 

【まとめ】

今年は初心者という域でしかセッションを聞けなかったので次回はちゃんと込み入った話を聞きに行きたいと思いました。あとどうせならめちゃくちゃandroidに触れて次回は登壇者としてやってみたいなという思いがふつふつと湧いています笑。

 

終わり。

 

 

エリック・エヴァンスのドメイン駆動設計

エリック・エヴァンスのドメイン駆動設計

 

 

 

実践ドメイン駆動設計 (Object Oriented SELECTION)

実践ドメイン駆動設計 (Object Oriented SELECTION)