CBcloud Advent Calender 22日目の記事です。
CBcloud株式会社で今年の1月からPickGoというサービスのバックエンドエンジニアとして勤務しています。
スタートアップのエンジニアは初めての体験です！ ドキドキ
そんな私の入社してからの約一年間の自身とサービスの成長を振り返ってみたいと思います。
1月
まだ入社したばかりで、自社のサービスについての説明の研修や、当時は電話対応等の研修も受けていたのでほぼそれに追われていた状態でした。
研修中に本番のPC側の画面に自信のユーザーを作成してPickGoというサービスでどういったことが行えるかの説明を受けてましたが、その最中にいきなり画面が真っ白になってしばらくつながらなくなったことを覚えています。
本番の画面です。Sandbox環境ではないです。
まだ何も知らない+先輩エンジニア達に止まっちゃってまーす って伝達すればよかったある意味幸せな頃
1月のほぼ終わりかけくらいの頃にPickGoを使用してお仕事をしてくれているドライバーさんに半日付き添う研修があったりもして、生の声を聞きましたが、自分がまだサービスの特性等を理解しきれていなかったので半分くらい空気を読んで頷いていました。
今行ったほうがもっと有意義なのかな？ と思っています。
2月
全くの新機能を2機能ほど自力で実装しました。
メインの技術スタックはRailsらしいのですが、大人の事情でがっつりScalaとAngular(JS)を書きました。
基本的に新機能や、付加的な改善であれば原則としてRails側で実装するのですが、都合によってはScala側で実装したりもしますし、あわよくばScalaに再統一してやろうと企んでもいます。
頑張って実装したのですが、本番ではあまり使われることがなく、現在泣く泣くそいつらのリソースを消す作業をしていたりもしています。フロント～バックエンドまで一気通貫で実装させてもらえたので、立ち上がりのインプットととしては非常に有意義であったなと感じます。
この辺は良くも悪くもスタートアップらしさを感じますね！
3月
弊社、いろいろあってバックエンドのサーバーがGCPとAWSにまたがるなんちゃってマルチクラウドで運用しているのですが、エンジニアチームの方針としては、今後はAWSに統一したいという意向かつ、面接時に「それなら僕、AWSについては(当時の)現職でだいぶインプットがあるので手伝いますよ！」と喋ってしまったのが災いしてか、移行先のAWS環境のインフラ設計～移行手順の策定までをまるっと任されました。
かつ、運用時の効果検証等でビジネス部隊から開発部署あてに、DBから分析に必要なデータ出しの業務依頼が日に一件ほどは来ていて、その都度SQLを作成してリードレプリカに対して直接発行して、CSVに加工して渡すという業務があったのですが、その辺りを自分がまるっと引き継いだ際に、「人間がやる作業じゃなくね？」と思って定期的に必要な分はすべてシステム側から任意のタイミングでCSVとして吐き出せるように(雑に)開発してシステムに組み込んだのもこの頃だと思います。
今では、DataStudioやmetabaseといったツールを利用してのデータの可視化といった辺りまでデータ分析に関する基盤は整ったのですが、マンパワーに依存した業務から自動化へという流れを作ったのは間違いなく自分であると確信しています。
某Bold社が「2回以上同じ業務をしたら、それは自動化の対象だよ！」といっていたのをどっかのイベントで聞いたことがあるのですが、とてもいい言葉だなと思いますし、意識して実践するようにしています。
4月
この頃は少しPickGoの開発チームとしては一つの転換期を迎えた時期ではないかな？と思っています。
今までイケイケで突き進んだ開発をしてきて、運用でカバー案件が多数あり、一日の半分以上が運用でカバーの尻拭いに追われるという現状を憂いて、運用でカバーしてる部分のシステム化をちゃんと工数取って行いましょう！ という合意が取れたのもこの頃でした。
また、監視基盤や、APMツールとしてDatadogを半ば強引に自分が導入(この頃から長らくの間、社で決済が取れずトライアル状態のまま Datadog社様ごめんなさい)し、システムのボトルネックを洗い出して、パフォーマンスチューニング等の動きもしだせるようになったのもこの頃です。
現在では、入社当時よりもシステムの利用度が倍以上伸びてるのですが、そこを大きな事故なく何とか支え続けることができているのも、この時期の動きの変化があったお陰かなと感じています。
5月~6月
長くなってきたので2月単位で
4月の時点で、AWS移行先のインフラ構成と移行手順は固まっていたので、移行第一弾が行われましたが、git管理されていなかったPlayFrameworkの設定ファイルの転記ミスというTHE ヒューマンエラーにより移行が失敗しました。
そしてまだ現在もGCP、AWSのなっちゃってマルチクラウド状態での運用保守が続いているとはこの時には思ってもいませんでした...。
インフラ構成自体には問題がなかった分悔やまれる...。
具体的な手順や、どんなインフラ構成にしたのかはどこかの機会に話せたら話したいなと思っています。
7~8月
この時期になんと、先輩エンジニアが一名退職してしまい、PickGoのバックエンド開発業務のほぼ8~9割が自分に寄ることになります。
この辺りからは、移行リベンジを見据えて、こちらでデータが動いてしまうのを制御できない部分、主にユーザー起因でデータが動いてしまう部分の機能のScala→Railsへ移行作業が本格化しました。
Rails側のサーバーは既にAWS環境で動いているので、ソースコード単位で移行しちゃえば実質AWS移行だよ！ やったね！ というとても頭の良い作戦です(・▽・)
はい。GCP上で動いてるScalaサーバー側の機能を自分たちでデータが動くのをコントロールできる部分のみにしちゃえば、安全に移行できるよね？ という魂胆です。
なぜここまでするのかというと、DBもGCP上で動いていて、DBはDBでAuroraに同時に移行するという計画であるからです。
確か8月にAWS側で大規模なAZ障害がありましたが、フロント、バックエンドの7割くらいの機能、DBがGCP上にあるため、ほぼノーダメージでした。
ほぼ以外の部分で何してたかはこちら参照
負荷分散のためにDBをmasterとリードレプリカで2インスタンス用意しているのに、実はRails側は、参照系も更新系も全部masterを向いていてDBが悲鳴を上げていた
ということが発覚して、慌てて複数DB接続対応したのもこの辺り
Railsで複数DB接続する
9月
ここはひと月だけで
今までは、軽自動車での配送のみ
本州の最北端～九州みたい配送依頼も軽自動車でぶ～んだったのが、飛行機と連携したことにより、より安くよりすばやく配送が行えるようになりました～ ぱちぱち
この機能に関しては、丸っきり新しい機能要件だったので、DBのデータ構造の設計~バックエンドのAPIの設計、開発をほぼほぼ丸っと担いました。
なかなかハードワークしたなと...。
粗削りな部分もあるので、まだまだ機能改善は続いています。
あと、デプロイ作業を今まで(特にGCP側のScalaサーバ)は直接SSHで入って、既存プロセスを切ってビルドして、プロセス再起動というヒューマンエラーの匂いがぷんぷんするデプロイ体制だったのを、CircleCIとJenkinsとちょっとシェル芸を用いてシステム化してやったのもちょうどこの頃
当然ですが、整備してからはリリース作業でのミスが0になりました。
リリース作業めっちゃ楽になりました。
本当はAWS移行後の環境に関してはもっと前の段階の自分が用意していたのですが、移行のリベンジの目途がなかなか立たない状態を憂いて、シビレを切らして構築しました。
後悔はしていないです。
この辺は、既存の手作業をコード化しただけで特に新規性もないので構築内容の詳細はとばしま～す。
消費増税前の駆け込み需要で一日の利用度の最高値を更新したがこの月の月末の平日です。
GW10連休前にも駆け込み需要があり、そのときは、サーバーが何時落ちないか冷や冷やしていた＋画面が一瞬真っ白になってサーバから応答がない ちょっとしたら復活する みたいな現象もあって気が気でなかったのですが、コツコツした改善の積み重ねのお陰で、この時期は余裕ぶっこいていられました。
10月～11月
前月までが割とコンスタントに刺激的だった分、もう慣れ切ってしまったのかいろいろな意味で心安らかに過ごしております。
地道な設計改善や機能改善をしています。
12月
一年で一番配送需要の高まるかき入れ時！！
きっと大変です！
まとめ
エンジニアとしては、常に考え抜いた最善を尽くした設計と実装を行いたいものですが、ビジネス側の要求を満たすためであったり、サービスの成長のし時を逃さないためには、負債を築いてしまっているなと感じつつもとにかく世に出すことを優先したり、余裕があるときにはそうした部分の改善を行って、次のビジネス要求を要求されるスピードで実装できるように整える必要もあるという、その辺のリソース配分のバランス感を楽しめるのもスタートアップならではだな ってここ最近は思えるようになりました。
以上
明日は弊社随一のRailsエンジニアである@shin-m さんの記事です！