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

今回はMFのエンジニアを招いてGEPPY開発秘話を話してもらいました！！
わたし自身知らなかったこともあって、GEPPYというサービスにより愛着が湧きました～🫶
エンジニア志望の方は必見の記事ですね！

GEPPYとは

GEPPYは、LINE公式アカウント上でレシート応募型のキャンペーンが簡単に実施できるキャンペーシステムです。
LINE公式アカウント と接続して
・LINEメッセージの配信
・Bot応答
・友だち追加の経路やURLアクセスの計測
・その他タグ付け機能などによる友だちデータの管理と検索
・外部サービスとの連携用API
など、LINE公式アカウントを管理・運用するシステムです。

今回の登場人物

🎀野口

2018/02 にマインドフリーに参画。
エンジニアとして複数の自社サービスの新規開発と運用保守を行ってきました。
APIの設計・開発が特に好きです。

🍀岸田

2023年4月入社の新卒エンジニア（ピチピチです✨）
学生時代は情報工学の特に画像処理を専攻していました。
現在は主にLINEキャンペーンツールの開発に携わらせていただいています。

GEPPY1開発当初

👾浅井
ではおふたり、よろしくお願いいたします～！
早速ですが、GEPPYの開発秘話を教えていただけますか？

🎀野口
はい！当時、2018年くらいにGEPPYが初回リリースされているんですが、
僕が入社したのが2019年だったんで最初のリリースは携わってないんですよね。

ただ、僕が入社の頃にはもう結構大きな案件も受けていて、
正直、めちゃくちゃ大変でしたね・・・(笑)

🍀岸田
そうなんですね。
うわ～　確かに立ち上げ期ってめっちゃ大変そう・・・

🎀野口
正直言って、今だから言えるんですけど開始当時のGEPPYの信頼性は低かったと思います・・・
同じタイミングで大量にLINE公式アカウント友だち追加してもらう時なんかは
このままだとサーバーダウンするんじゃないかと背筋も凍る思いを何回か経験しましたね・・・

🍀岸田
それ、土日も気になってゆっくり休めなさそうですね・・・

🎀野口
まさにそうでした・・・

僕は2月に入社してるんですが、毎回案件でキャンペーンやる度にダウンしたらどうしようっておびえながら過ごすっていうのがゴールデンウィークまでの3ヶ月間くらいは続いていましたね。

🍀岸田
最近入社した僕としては、過去の先輩方、ありがとうございますって感じです(笑)

エンジニア野口成長物語

🎀野口
実は開発以外にも苦労はあって・・・
僕以外のエンジニア2人が6月に辞めることになったんですよね。
正直入社から4カ月しかたってないんで、ほぼ何もわかってない状態で僕1人取り残されたんですよｗ

👾浅井
お～～～～～なんともアツい環境ｗｗｗ

🍀岸田
しかも野口さんって文系出身でエンジニア歴としても1年くらいでしたよね？！？！

🎀野口
そうなんです(笑)
営業さんが、頑張って、大きい案件取ってきてくれてた時期でもあったので
その頃から社内的にもGEPPYサーバーの負荷をどうやって耐えれるようにしていくか、が
一番重要な課題として挙げられ始められました。

👾浅井
ちなみに、ほぼ第2新卒みたいな感じで誰もエンジニアが居なくなってどうやって勉強したんですか？

🎀野口
そうですね・・・その時は必死だったんであんまり覚えてないんですけど・・・(笑)
仕事中にコードを読んで、そもそもこの書き方いいのか？とかを常に考えてましたね。
わからなければ、こういう書き方があるのか！とか、こういう開発手法あるんだな！とか、
細かいことでも調べていましたね。要はチリツモです(笑)

元々、同じ文系卒の人よりもうまくプログラム書けるようになりたいとか、
理系の人に負けないエンジニアになりたい！
みたいな憧れがあったので、競争心みたいなのは持ってましたね。

🍀岸田
その競争心があったから、受け身じゃなく自分から色々取り組むことができるようになったんですね。

👾浅井
出来る子だ・・・🥹
できなかった時代の野口くんを知らないから驚きです。

🎀野口
あの頃は、「こういう機能作りたい」って要望きても、
どうDBの定義を設計すればいいのか？どういうプログラム書いたらいいのか？
どういうAPIを作ったら実現できるのか？が全く分からなかったですからね。
完成品のイメージも浮かばなかったです😅

チューニング時代

🍀岸田
その後、サーバー負荷を減らすためのチューニング時代が始まると思うんですけど、
その時エンジニアは野口さん1人ですよね？

🎀野口
そうね。しんどかったです・・・(笑)

どうなっていたかを簡単に話すと、
AWSのEC2を構築して、webサーバーはApachで、処理するプログラムはPHPで、DBはRDS使って...
といった感じのよくある構成で動いている状態でした。
それぞれのステップにチューニングする改善点を1個1個見つけていく作業とかもやりましたね。
まずは、プログラム的に効率の悪い処理をしてないかどうかをチェックしていきました。

色々なモジュールのインポートの処理をトータルすると1リクエスト0.8秒くらいかかってましたね・・・
たぶん1リクエストで、インポート含め処理が完了するまで最大1.5秒程度かかるパターンもあったと思います。
いらないものをインポートしてるとか、同じものをインポートしてるとかを見つけて削っていって…という超地味な作業もしましたね。
DBへの接続回数を減らすよう効率化したり、PHPのOPcacheを入れたりして、0.3秒ぐらいに収まるようになりました。

🍀岸田
ちなみにその当時のGEPPYの問題として管理画面がめちゃめちゃ遅かったみたいな事があったんですよね？

🎀野口
それもありましたね。

GEPPYはLINE公式アカウントと接続して、友だちの管理をしたりするツールでもあるんですよ。
その友だちの検索機能が、検索条件にもよるんですがとんでもなく遅くなることがありまして、2分ぐらい待たされることも・・・

🍀岸田
そ、それは・・・😅

🎀野口　
今だから言えますけど、本当に良くない時代やったと思います😔
この問題は後々、GEPPY2に移行するきっかけの1つですね。

大量データの検索周りの課題と、日々のユーザーから送られてくるリクエストを捌く時に負荷に耐えられない、というのが2大課題でしたね。

悟り時代

👾浅井
その2つの課題を地道に解決していく、みたいな時代が続いたんですか？

🎀野口
それが、プログラムを直せばできるっていう感じの範囲をやっていってたんですが、ある日気付いたんです・・・というかあまりにも大きすぎて目を背けていたといいますか・・・根本的な課題は、最終的にDBだということに・・・

🍀岸田
・・・まさか😧

🎀野口
これは、チューニングとかのレベルじゃなくて、 そもそも根本からデータの効率のいい持ち方とかを考え直さへんと無理だなと思い始めてきたっていう・・・

プログラム頑張って色々直して、Apacheのチューニング、SQLクエリのチューニング、と色々したりしたんですよ。

試行錯誤しながら元々秒間20~30リクエスト程度しかさばけなったのが、最終的には300リクエストぐらいまで耐えれるようになりました。ただそれ以上を目指そうとすると、やっぱりDBが良くないと言う結論になりました。

🍀岸田
DBは後から変えにくい箇所No1ですからね・・・😨
それは、設計が良くなかったんですか？

🎀野口
そうですね。ぶっちゃけ言うと設計が結構悪くて・・・

例えると
家で、 風呂とトイレの場所どこ？！？！って探したら
えーーー！2階の端っこあるんかーい！これ動線どうなってんねーーーん！！

って感じです(笑)
風呂とトイレの場所を変えるのは無理だから、もう一から家を建てようってことですよ。

👾浅井
ひゃーーーーー！大変っ😨

🎀野口
そうやって、悟りを開いていきましたね。

当時はRDSを使ってたんですが、テーブル設計を1から見直したり、検索用途でElasticsearchを導入したり、新しく作り直したほうが将来的にも良いんじゃないかと思って。

それを役員や上司に提案をしてみると、多分 今のままだと抜本的な解決は厳しいんだろうなっていうのを感じてくれたみたいで、割とすんなりと受け入れてもらえましたね。

🍀岸田
ここから、GEPPY2の開発が始まる訳ですね。

🎀野口
そうです！半年～1年くらいかけてやりましょう、となったのが2020年1月ですね。
ここから技術選定、言語選定とやっていくんですが、ここからも大変だったんですよ・・・

👾浅井
めちゃくちゃ気になりますが、尺的に次の記事になりそうです(笑)
語りたい事が多すぎますね！次回も乞うご期待ください！！

後編に続く・・・