こんにちは！
コーポレートマネジメントチームの浅井です 👾

前回はMFのエンジニアを招いてGEPPY開発秘話を話してもらいました！
紆余曲折あり、GEPPY1からGEPPY2に進化させる！と会社で決断するまでの話をしました。

後編では、具体的な技術選定や言語選定についてお話していますのでご覧ください👀

GEPPY2 技術選定

👾浅井
ここでやっと、今わたしが知っているGEPPY2の開発が始まるんですね！

🍀岸田
まずは技術選定からしていった感じですか？

🎀野口
そうです！
GEPPY1はRDSを使ってたんですけど、もっと検索が早くて負荷にも強いDBは無いか、とか
プログラムだけじゃなくてそもそもEC2を使うべきなのか、とか全ての見直しを始めました。

そのタイミングでもう1人エンジニアの方が入ってくれて、
2人でこれがいいんじゃないか？あれがいいんじゃないか？っていうのを議論・検証して、
最終的な技術選定と大まかな仕様の決定までで、おそらく3か月ぐらいかかりました。

🍀岸田
その時、野口さんエンジニア歴2年目とかですよね？！
2年目から技術選定に携われるのはめっちゃいい経験ですよね！

🎀野口
ですね。多分僕がその当時エンジニア歴10年目とかだったら、こんな柔軟な発想できなかっただろうな～とは思います。 webアプリってこういう構成で作る、っていうスタンダードの考えが凝り固まっていたと思うんですよ。
ただ当時の僕は2年目なんで、その作法を知らなくて。 ある意味自由に柔軟に考えることができましたね。

👾浅井
まさに0＋αを体現してるじゃないですか👏

🎀野口
枠に捉われずに新しい価値を生み出しましたね😅

👾浅井
結局DBは何にしたんですか？

🎀野口
やっぱりRDSで痛い目を見たんで、そもそもRDSを使わないDBって何があるんだろう？というとこから調べました。
そうするとたまたま同じようなことを思ってる人が世の中に沢山居て、代わりにこれいいよ！みたいな記事が上がってたんですよね。

🍀岸田
それがDynamoDBだったんですね。

🎀野口
検索機能はないんですが、負荷だけにはめちゃくちゃ強くて、職人みたいなDBだったんです。
GEPPYはリクエスト数も多いので、候補としてはいいかなと思いました。
ただ、もしDynamoDBを使うとなったら、検索機能はどうする？ってなるんですよ。
それで、負荷の職人がいるなら検索の職人もいるでしょう！と思って探し始めたんです。
そうすると調べてみるとElasticsearchという検索エンジンがあって…

👾浅井
お～！名前からして「検索やります🔍」って感じ！(笑)

🎀野口
データを永続的に保持するデータストアではなくて、1000万とか1億とか大量のデータの中から、高速に検索結果を返しますよ、検索条件を色々柔軟に設定できますよ、という検索特化のやつなんです。
そこで、じゃあDynamoDBで負荷に強いデータストアの役割に担わせて、Elasticsearchで検索させれば最強やん！って思ったんです。

🍀岸田
でもそれが正しい構成なのかという不安はなかったんですか？

🎀野口
ありましたね。
なのでネットで色々と検索したら、そういう構成を実際に試してみた記事がいくつかあったんですよ。
規模がある程度大きいサービスで運用しているケースもあってそれで決心が付きましたね。

GEPPY2 言語選定

🎀野口
DBの目途がたった後は、プログラム言語の選定に移りました。
結論から言うと、管理画面などメインの処理をPHPでその他一部の処理をGoを使うことに決めました。

🍀岸田
GEPPY1はPHPだったんですよね？

🎀野口
そうです。当時はCakePHPやLaravelといったフレームワークが流行りだったんですが、GEPPY1は1～2世代ぐらい前のZendFrameworkを使ってましたね。
ZendFrameworkを使い続ける理由が特になかったのと、今もですが当時からLaravelがデファクトスタンダードの風潮があったので、フレームワークはLaravelを使いたいなと思いました。
当時の僕のレベル感的に、全く経験のない言語とフレームワークで作り直せる自信がなかったので・・・
管理画面のサーバーサイドは、割とすぐにPHPとLaravelを使うことが決まりましたね。

🍀岸田
Laravelにしてくれてよかったです(笑)
フロントエンドはどうしたんですか？

🎀野口
これは僕の欲もあったんですが・・・
GEPPY1ではjQuery を使ってたんですけど、その当時Vue.jsやReactが流行っていたのもあってVue.jsを選びました。
Vue.jsやReactだと、サーバーサイドとのAPI連携がしやすく、データの描画もかなり楽なので。
サーバーサイドの処理はできるだけAPI化して、フロントからはAPIで取得したデータを描画するというように、役割をソースコードレベルで分離できることにとてもメリットを感じましたね。

個人的には今後エンジニアが増えた時、フロントとバックエンドでそれぞれチームが分かれて開発した方がいいのではないかと思っ ていたので、使わない理由は無かったです。
ReactではなくVue.jsを選んだのは、一応使いたいUIライブラリがあったとかもありますが、単純に僕ともう1人のエンジニアの好みの部分が大きいかもです(笑)

👾浅井
なるほど！会社の将来的なことも考えてくれてたんですね！

🎀野口
漠然とですけどね(笑)
次は、line公式アカウントから、友だちに追加された時の処理についてなんですけど、実はここが1番負荷が高い処理なんですよ。

ここも新しく好きな言語使ってもいいし、サーバーも特殊なやつにしていいし、と自由に選べたんですけど、ここは検索処理よりは、1秒間にいっぱいアクセスされても耐えられるような構成にしたい！という明らかな課題があったので、それに担うような技術選定を行いましたね。

まずプログラミング言語の前にサーバーをどうするかというところです。
DBはある程度負荷に強い構成になったんですけど、構成を工夫せずにEC2を使っていたらリクエストが多ければサーバーがパンクするので、サーバーももっといいのないかな、と色々探してました。

🍀岸田
タイミング的にも色々なサーバーのサービスが出てきてましたもんね。

🎀野口
結果、サーバーを用意しなくていいAWSのLambdaに決めました。
Lambdaはリクエストされるたびに、 そのAWS側で勝手にサーバーを起動して、リクエスト処理が終わったらサーバーを停止してくれるんです。
沢山処理しても落ちにくいし、1秒間に1000～2000のリクエストが来た時にも一部負荷はかかるんですが、 2～3秒後にはすぐ復活してくれるんです。

サーバーへの負荷が課題だったので、「これいい！」ってなったんですよね。
他社の技術ブログとかでも凄くいいという記事も多かったですし。

🍀岸田
明らかにGEPPY1の時よりは捌けそうですね！

🎀野口
次にプログラミング言語を決めようと思った時に、プログラミング言語もこだわりたいという想いがありました。
結果Goを採用するのですが、理由としては、処理速度がシンプルに速い、並行/並列処理が比較的書きやすい、エラーをないがしろにしない言語設計、ですかね。後々のメンテナンスもしやすい。
今はわからないのですが、Goが使われているサービスにDockerなどめちゃくちゃメジャーなものがあったので、信頼性もあるなと思いGoに決めました。
あと結局個人的にGoを使いたかったっていうのもあります(笑)

👾浅井
キャリア的にもPHPだけじゃなくGoも使ったことあります！って言えた方がエンジニアとしてやっぱり強いですもんね！

🎀野口
こうやって単純にGEPPY1の課題だったことに対して、技術選定で課題を潰して解決していくというのと、最終的にはデータの持ち方などもっと細かいチューニングはしていたのですが、ある程度の技術選定はこんな感じで進んでいきました。

🍀岸田
なんかさらっと行きましたけど、結構凄まじいことしてますよね(笑)

🎀野口
岸田くんのいう通りその当時の僕のレベルでよくやろうと思ったな、と今振り返ると思いますね(笑)
もし今の僕が、当時の僕の先輩エンジニアだったら「ほんまに自分の実力でできると思ってるん🤔？」って忠告すると思います(笑)
ただ、MFの良いところは攻めが出来ることなので、チャレンジも大事だなとも思いますね(笑)

👾浅井
素人目線からだと、もっと簡単なやり方もあったんじゃないか？とも思うんですけど、当時なんで攻めようと思ったんですか？

🎀野口
もう切実に、サーバーが落ちたりする状況を2度と作りたくないという想いだけでしたね。
もちろん責任感もありましたが、自分たちが嫌な思いもするし、ちゃんと土日は心身ともに休みたいので頑張りました(笑)

👾浅井
2020年の1月ぐらいから4月くらいまで選定作業が続いたわけですよね？
もちろんGEPPY1の運用もしながら・・・ですよね？

🎀野口
そうですね。
割と半分以上は、考える時間や調べる時間に充てたり、実際にElasticsearchに1000万件くらいデータを入れて何秒で帰ってくるかを検証したり、と細かいところまでやってましたね。

👾浅井
めちゃくちゃ大変そう・・・よく乗り越えましたね・・・

🎀野口
大変でしたが、本当に勉強になりました。
初期の設計が結構課題が多かったので、反面教師になる素材が全部揃っているというか(笑)
今となっては「こういう事はしたらダメだね」と思えて、もはやありがたかったぐらいです😂

🍀岸田
僕が当時の野口さんやったらそんなにポジティブに考えられない(笑)

🎀野口
僕も、当時はそこまでの考えに至らなかったですよｗ
でも、エンジニアにとってはこれがダメだっていう悪いものを見ることは大事だと思いました。
こういうのやったらあかんねや！を積み重ねて成長してこれたのかなと僕は思ってます。

そういう挑戦を、会社も経験の浅い自分によく任せて任せてくれたな～と感謝してますね。
作り手として良いものを追究することができる環境にしてくれたなと。

🍀岸田
野口さんのおかげで、MFって近年のいわゆるクラウド型開発がちゃんとできているんだなと思います。
EC2などがなかった時代だとエンジニアも何十人と必要で、インフラエンジニアも必要で、ってなると思うんですけど、MFみたいな少数精鋭のエンジニア部隊だとインフラまでなかなか手が回らないですからね。

野口さんは運やタイミングが良かったと話してましたが、そこら辺の手が回らない部分をDynamoDBやLambdaで、うまいことその時代の開発手法にフィットするようにしてきたんだな、というのが凄いです。
おかげで今は開発者は開発だけに集中できるっていう環境になってます！

🎀野口
そう言ってくれると嬉しいです。ありがとう！

当時を振り返ってみて

👾浅井
苦労して作ったGEPPY2が完成した気持ちはどうでした？

🎀野口
そうですね、素直に嬉しかったです！
ただ、リリースした後もGEPPY1の契約してるクライアントを、GEPPY2に移行する作業は残ってたんで、それも半年ぐらいかけて徐々にやってたという意味では「やったー！終わった！」って感じではなかったんですけど(笑)

でもまずは、ほぼ1年ぐらいかけて考えて開発したサービスが動いた時は、凄く嬉しかったですね！

👾浅井
この経験を通して感じた事はありますか？

🎀野口
経験を通して0.8人前ぐらいにはなれたかなっていう感じはしましたね。
まだまだプログラムの書き方とかで全然良くない 課題はいっぱいあるんですけど、今思っても思っても技術選定だけは グッジョブだと思います👍
当時の自分を褒めます(笑)

🍀岸田
いや～ほんとうにグッジョブです👍👍👍(笑)

👾浅井
色々とお話を聞けて良かったです！ありがとうございました！！

次回は、🍀岸田くん🍀の新卒エンジニアインタビュー記事をアップ予定です★

／　お楽しみに～　＼