チームとの信頼関係がプロダクトの信頼性につながる。MOVOを影から支える大黒柱にインタビュー

今回はプラットフォームチームリーダーのくろださんにインタビュー。MOVOのフルリプレイス時から一貫してインフラと共通サービスの開発に関わり、安定運用を支えてくれています。プロダクトチームに寄り添い続け、Hacobuの全エンジニアから信頼されるプラットフォームチームを育て上げたくろださんに、今回のSRE募集についてお話を聞いてきました。

Q. プラットフォームチームのミッションを教えてください

2019年にPF基盤チームとして2人で活動を始めました。当時MOVOのフルリプレイス(※1)を実行することになっておりMOVO Berth,Fleet（※2） と共にインフラも一新するため同時に開発をスタートしました。現在はプラットフォームチームとして一貫してインフラ管理やSRE・共通機能の開発を行なっています。次の5つをミッションとして掲げています。

• MOVOのクラウドアーキテクチャの構築・運用
• MOVOの監視やチューニング等の運用
• インフラコストの最適化
• プラットフォームエンジニアリング
• プロダクト共通機能の開発・運用

※1
MOVOフルリプレイスについてはlogmi Tech の対談をご覧ください
https://logmi.jp/tech/articles/328433
https://logmi.jp/tech/articles/328434

※2
Berth トラック受付予約サービスMOVO Berth　
Fleet: 動態管理サービスMOVO Fleet

Q. くろださんはどのような経緯でHacobuへの入社を決めたのですか?

入社したタイミングはCTOの戸井田が入った2ヶ月後でした。入社したのは会社が自宅から歩いて通える距離であることも大きかったのですが(笑) 実家が運送業を代々経営しておりドライバーの運賃が下がっているのはよく理解していて、MOVOではこの問題を解決しようとしていたことに強く共感しHacobuへの入社を決めました。

Q. 入社後、MOVOフルリプレイスに貢献しました。今までどのような開発を行なってきましたか?

入社当時はMOVOのフルリプレイスプロジェクトがちょうど進み始めたタイミングでした。マイクロサービスアーキテクチャで実装していくという方向性はできていましたが、さぁ何から作ろうか、という状態でした。

チームではまず共通認証の仕組みから作り始めることにしました。この仕組みはミドルウェアもしっかり整備することができて、結構成功したのではないかと思っています。プロダクトチームから見るとミドルウェアのライブラリを参照すればそれだけで共通認証の仕組みにのっかることができ、新プロダクトを開発する時も作りたいものに集中できる状態になっていると思います。

共通認証以外にも通知基盤や共通マスタなどの共通機能開発・マイクロサービスを運用するのに必要な共通ミドルウェアの開発を行なっています。共通マスタというのは、例えば車両マスタはFleetでもVista（※3）でも利用するのでPF基盤チームで開発し、両方のプロダクトから利用する形にしています。こうすることによってFleetとVista両方を使うお客さんがいたとしても一度のマスタ登録で済むことができ、プロダクト間連携を行う際にも共通のIDを使ってやりとりできる状態になっています。

※3　
Vista: 配送案件管理サービスMOVO Vista

2020年のファーストリリース時には20個程度のサービスでスタートしました。今ではだいぶ増えて、90個くらいのサービスが動いています。サービスの数は増えましたが、Kubernetesの仕組みを利用しつつ自前でもリソースを柔軟に管理しやすい仕組みを整えているので、あまり苦労は増えていません。ただ、アップグレードが必要なOSSのミドルウェアが増え、それに応じた変更箇所の把握と影響の検証も増えたので苦労している部分もあります。

DatadogのServiceMapキャプチャ

Q. 直近で特に力を入れてきた部分はどんなところですか?

可観測性とプロダクトのパフォーマンス改善（≒コスト増加を抑える）です。

可観測性については最初から力を入れていきたいと思っていました。実際フルリプレイスした後に何が起こるか分からなかったので、Datadogの分散トレーシングを利用して全てのサービスのログを横串で見れるようにしていきました。一つのhttp request に対して結構な数のサービス・データストア・外部APIが連携して動くことになるので、何か問題が起こった時の調査を楽にすることはとても重要なことでした。現在ではRUMも導入していて、ユーザ側のネットワークを含めどこがボトルネックになっているのかが分かるようになっています。

ログの整備を頑張ったことにより、プロダクトのパフォーマンスが客観的に測れるようになりました。アラートを整備したり、ダッシュボードをパトロールしてチームへ改善提案をしたりしています。パフォーマンス劣化によるコスト増加も結構抑えられています。

改善の一例。p99で722ms → 16ms と驚異的な改善を達成した。

Q. コスト最適化はどのような取り組みをしていますか?

Datadogを導入した際になんでもかんでも投入していたら、Istio のログが10億行くらい吐き出されてしまいました。幸いなことに導入検証時の無料枠が利用できたので事なきを得ましたが、運用時の料金で計算するとかなりの額になることがわかってビックリした、なんてこともありました。そんなアクシデントがあったこともあり、ログコストへの意識は高まりました。

もう一つ記憶に残っていることがあって、フルリプレイス後に旧環境のAWSリソースが残ってしまっていたことがありました。リプレイス後だったのでそのリソースは実は不要で、そこそこの額を無駄にしてしまいました。役割的には別の人が見ている部分ではあったのですが、インフラに責任を持つ部署としてオーナーシップを強く持つ必要性を実感したエピソードでした。

このようなことがあったので、今では月一でコストを元にした振り返りをするようにしています。コストの最適化と、コストの変化からリソースの異常を探る取り組みです。この振り返りにより、今まで月々数千円だったものが数万円にコストが跳ねてしまったのを検知したことがありました。その時は担当のプロダクトチームと連携しインフラ設定を見直すことで元に戻すことができました。さらにこの活動はコスト最適化が一番大きな目的ではありますが、原因を探ることがメンバーのスキルアップにもつながっているので、その点でも有意義な活動であると思っています。

Q. 今後はどのようなことに力を入れていきたいですか?

プラットフォームエンジニアリングに力を入れていきたいと思っています。今までの活動としてもなくはないのですが、良くも悪くもチームで巻き取って対応しているので開発者が自身で動きたいと思っても中々できないことがあります。PR単位で環境を作れるようにしたり、検証環境を簡単に作れるようにしたりして各プロダクトチームがオーナーシップを持って開発効率を上げていける流れが作れると良いなと思っています。

Q. どのような人がHacobuのSREとしてマッチしますか?

プラットフォームチームはプロダクト開発の主役ではなく、あくまで脇役であると思っています。なので基本的にはプロダクトチームが動きやすい・生産性の高い環境を整備していくのが仕事です。もちろん例外はあってセキュリティの関係で譲れないラインというものもありますが、チームを支援し、チームとの信頼関係を大事にしていくことが結果としてプロダクトの信頼性につながると考えています。なので技術一直線というよりはユーザ目線を持ちall hacobuとしてみんなでプロダクト開発していける方がマッチするのかなと思います。

Q. 最後に何かあれば

今のMOVOはとても障害が少なく、顧客はもちろん、営業やCS・法務が困るような障害はほとんど起きていない状態を達成できています。もちろんプロダクトチームの努力あってのことですが、プラットフォームチームの貢献も大きかったと自負しています。このようにHacobuではプラットフォームチームとプロダクトチームがとても近い位置で働くことができており、成果も出ています。MOVOユーザの声もたくさん入ってきており、プラットフォームチームとしてプロダクト開発に直接貢献できる会社です。興味を持った方はぜひお話しさせてください。