はじめに

GraffityというARを使った落書き通話アプリを作っているむーつんといいます。好きな言語はJavascriptなサーバサイドエンジニアです。

弊社のAPIは元々Railsで出来ており、以下のような構成でした。

f:id:mtnnnnnnn:20180801164345p:plain

ここにはスケーラビリティは考慮されておらず、同じインスタンスをコピーしてALBに振り分けてもらうという粗末なものでした。（スピード感が求められるスタートアップにおいてはこれで良いのかも）

しかし、Graffityは過去にZIP!で取り上げて頂いたり、弊社代表の森本(以降Totti)がJ-Waveでラジオ出演するなどメディアへの露出が増える中、これではいつ大量アクセスでサーバがダウンするかわからず不安です。

ラジオ初出演！本日のJWAVE8:30〜9:00までARの未来について別所さんと話しました:) 森本節炸裂してるのですが、内容は面白いので是非！
もっとARの未来をわかりやすくビジョナリー伝えよう！貴重な機会ありがとうございました！#JWAVE pic.twitter.com/ozh0j4SPC7
— ᴛᴏᴛᴛɪ (@ok_totti) 2018年7月5日

Totti「むーつん、Goに興味ある？」

---それは突然訪れました。森本の兼ねてからの友人のI氏（インターンでUSの某大手SNSで働いた実績がありとても優秀と聞いていた）がサーバサイドの業務にコミットしてくれることになり、彼がGoに興味があった事と森本がGoに対して持っていた可能性から僕にサーバの開発をGoに移行した方がいいのではないかと打診があったのです。

Goのコミュニティの活発さは感じていましたし、前述のような課題感からRailsからGoに移行することを決めました。

さて、Goに移行するぞい

Goに移行するに当たって、以下の要素を重要視しました。

マイクロサービスアーキテクチャ
- PMF達成に向け、多くのプロトタイプを追加・削除しやすいこと
- サービス間通信が行えること
Infrastructure as Code
- マネジメントコンソールを触らずともインフラが構築できること
CI環境(デプロイ、テスト)
- ダウンタイムのないデプロイが簡単に行えること
- 自動テストを実行できること

最終的には以下のような構成になりました。

f:id:mtnnnnnnn:20180801164453p:plain

GraffityはPMF達成に向けて仮説検証を進めているフェーズです。今後多くのプロトタイプが生まれ、破棄されていくことを想定し、コアな機能（ユーザ管理、Worker）と各APIを疎結合することでリスクなく運用できると考えました。

また、インフラ環境はTerraformにてコード化されており、マネジメントコンソールから操作することなくコードベースで構築できるようになりました。これにより、人為的操作により環境が壊れたりするリスクを抑えることができそうです。

デプロイはecs-deployを用いて行われ、

稼働中のサーバ（Blue）とは別のサーバ（Green）を起動する(AutoScalingGroupのMax/MinSizeを0->1以上に変更する)
Greenにecs-deployを用いてECRからイメージをデプロイ
テスト用サブドメインにRoute53にてGreenのロードバランサに接続
テストコードが走る
テストが問題なければデプロイしたいドメインに対してGreenのロードバランサを接続（Blue -> Greenにスイッチ）
Blueサーバを停止する（AutoScalingGroupのMax/MinSizeを0に変更する）

上記コードをpythonでスクリプト化され、makeコマンドとして実行できるようになっています。

ポイントとしては、ELBに対するRoute53のTTLが60秒のため、5が完了後、60秒以内にBlueサーバを停止してしまうと、Route53はまだBlueに接続してしまうため接続エラーとなってしまいます。なので、スクリプト内で5の後に80秒ほどスリープしてから6を実行するように調整しました。