どうも、昨日ぶりです。
新規事業部 mofur でフルスタックエンジニアをしている高田です。
今回は後編です。 mofur が golang とどうやって付き合ってきたかについて書いてみます。
前篇をまだ読んでない方は、以下からどうぞ。
How to use golang?
mofur の 設計を行う上で、以下に気をつけました。
- 設計は簡素に。目的粒度単位でパッケージを切る。言語の性格に合わない、巷で囁かれるモデルを必要以上に意識しない
- なるべく関数的な動き（関数型プログラミングという意味ではないですよ）を目指し、プログラム自身が「状態」を持たないように努める
- セッション概念を投げ捨て、サーバを幾つでも並列に並べられるように意識する
- 並べたサーバ同士が互いに一切の通信を返さずとも、システム全体として協調して動ける、スタンドアローンコンプレックスを目指す
- アクセスは HTTP (HTTPS) 経由で、 GET か POST で要求を行う
- データは原則 JSON で返す
要は、 REST API として実現させることに重きを置くということです。シンプルです。そして、以下を必須としました。
- 富豪的プログラミングを絶対に許さない（メモリ１バイトは血の１滴と思え）
- AWS を使う上で、 EC2 の t2.micro （設計当初は最も低スペックなインスタンスだった）で動かしても、スパイクに十分耐えられるレベルで軽く作る
- シェルスクリプトでビルドが出来るようにして、CI 環境での運用を簡単にする
- 自動テストは必須とする
- １つのコードで debug 版と release 版のビルドが出来ること
- 改変耐性の強い仕組みを考える
私が golang を mofur に導入した当時は、 vendoring の概念がなかったので、それに準じた方法の設計も必要になりました。
Devising of mofur.
mofur は、状態を持たない仕組みになっています。その為、構成もかなり簡単です。
たったこれだけです。 EC2 の部分に golang で書かれたアプリケーションがいます。このEC2は複数台並べることが可能です。
データを扱う機能は全て外出しです。 DB は RDS に、その他のデータは S3 に。S3 上のデータ配信は CDN を噛ませています。 AWS でよくある一般的な構成で、何の面白みもありませんが、 golang との相性はこれがとても良いのです。
S3 と EC2 の間のやり取りは、 AWS SDK for Go を使って書きました。
RDS と EC2 の間は genmai と go-mysql-driver で実現しています。
EC2 と アプリ、または Web 版 mofur の間は echo にて機能が実現されています。
まったくもって、理解しやすい簡素な仕組みですね。
もし AWS を使っていなければ GCP の GAE で組んでいたと思います。 GAE と golang 、凄く相性がいいそうですよ。私が知っている限りでも、 golang を導入し、成功したサービスを運用されていて、「 GAE 使ってるよ。安くついたし、動作速度も全然不満がないよ」と言っているところは少なくありません。
How to Deploy.
deploy には Python 製の Fabric というツールを使っています。 CI 環境として Jenkins を入れたサーバを用意しています。その上でビルドを行い、実行ファイルを各実行サーバへ Fabric を用いて並列配信しています。
Fabric は非常に容易ながらも、協調性を持った並列制御に優れたツールです。私は系の維持に Immutable Infrastructure の概念を持ち込んでいますが、 Ansible や Chef を使うよりも遥かに簡単に目的を達成出来ています。
また、 golang で書かれたアプリケーションは実行環境で悩むことがほぼ無いため、 Docker を使うべきかどうかと悩む必要もありません。その分、実行環境が更に軽量になり、全体のトータルコスト（スペック的にも、金銭的にも、労力的にも）を低下させます。
ボタンを押せば全体に勝手に配信。実に楽な運用です。
Code scale.
現時点でのソースコードの規模は、 Web API 部分だけでおよそ 170 ファイルで 2.5 万行程度です。大体、 2 人・ 3 ヶ月足らずでこの大半を書き起こしました。
現在も、開発・運用・保守・新機能提案・ロードマップ作成等をザクザクとこなしています。今後も私が担当する作業領域とコードは増え続けていますが、コードに関してはリファクタリングを頻繁にしているため、「全体のエントロピーが上昇し続けてどうしようもならなくなる」、なんてことはありません。業務に関しても徹底的な自動化と、 golang らしいシンプルな設計をすることで、特に支障なく回せる程度に落ち着いています。
golang は業務そのものもシンプルにしていきます。如何にシンプルで在り続けられるかを問われ続ける言語でもあると、私は思っています。
Finally.
golang と mofur と AWS の関係についてさらっと触れてみました。 どうでしょうか、 golang は十分実戦投入可能な言語です。実際、既に昨年から mofur は golang で動き続けており、致命的なサーバダウンには今のところ見舞われたことがありません。言語の安定度としても、申し分ないかと思います。「 golang とか、まだまだ新しい言語でしょ？ 不安定なんじゃないの？」と思っている方、安心して使ってみて下さい。
またデベロッパーズブログを書く機会が回ってきましたら、 golang の並列処理とか、私がおすすめと思っている golang の書き方などについて書いてみようと思います。それではまた。
mofur のオフィシャル Twitter アカウントでは、 mofur 内のおすすめの動画や、 mofur 内のキャンペーン情報をつぶやいています。
話しかければ、中の人からの返事も貰えるかも……！
よろしければフォローしてください！
関連記事
