アソビューでVPoEとTech Lead時々SREをしているdisc99🐼です！
🐣はじめに
アソビューではサービス立ち上げから9年が経過しましたが、コロナなどの逆風化においても、創業以来、右肩上がりの成長を続けています。
この記事では、これまでのサービスの歴史と、その中で起こった問題から、どのような取り組みを行っているかを紹介しようと思います。
尚、今回の取り組みに関しては、主に技術的取り組みにフォーカスしています。
また、文中ではマイクロサービスに関わる話が出てくるため、各用語は以下の意味を指しています。
アソビュー：アソビュー株式会社（サービス名と会社名が同じため）
サービス：アソビューが運営しているEC、SaaSなどのプロダクト
アプリケーション：JavaやPythonなどで作られた1つのシステム
🌱サイロ化に至るまでの歴史
取り組みを紹介する上で、その背景となるアソビューの開発の歴史を簡単に説明させてもらいます。
2012年頃 サービス創業期：モノリスによる素早い開発、PDCAの実現
立ち上げた当時はまだアクティビティ販売の事業で収益化できていたサービスがあまりなく、事業者の方に参画してもらう障壁も高い時代でした。
そのため、少数の開発者で事業者の要望を素早くサービスに反映させるため、モノリスなアプリケーションで開発をスタートしています。
結果、素早い要望の実現を行い、初期のフェーズとして一定の事業者、ユーザーに使ってもらえるサービスとなりました。
2015年頃 成長期：アプリケーション分割による、素早い事業の立ち上げ、自立自走の実現
事業者、ユーザーが増えたことにより、今まで手作業や自社のメンバーで行っていた機能の一般公開、新たな商品種別への対応などが必要となってきました。
また開発者の数も10名を超え、コミュニケーションコストや既存のアプリションの柵に囚われず、新たな機能を素早く充実させていくことが、事業としてより重要性が増してきていました。
加えて、この先成長を続けるために、より柔軟性、拡張性の高い設計も必要となっていました。
その流れとして、既存アプリケーションの拡張するだけでなく、新規にアプリケーションを立ち上げることで、既存の資産に囚われず素早く顧客の要望を実現する開発のための取り組みが行われました。
具体的には、以下のような施策を推進していました。
- 事業者への予約管理機能の公開のためのアプリケーション立ち上げ
- 電子チケットなどの分野への進出のためのアプリケーション立ち上げ
- DDDなどこの先成長していくための技術戦略
こういった取り組みの中で、新たにアプリケーションを立ち上げるというアプローチは効果を発揮し、サービスの収益化が加速していきました。
2018年頃 事業の多角化期：マイクロサービス
順調な成長が進んでいく中で、遊びという商品を届ける事業として、オウンドメディア、カタログギフト、インバウンド、リセール、地方自治体へのソリューション提供など多角化が進みます。
その中で過去の成長実績、オフショア拠点の立ち上げも重なり、アソビューでもより自立性を高めるため、マイクロサービスを主体としたアーキテクチャが一般化し始めたのもこのくらいの時期でした。
過去同様立ち上げはうまくいくものの、この辺りからアプリケーション数も増加していく中で、開発体制は20~30人程度であったためサイロ化の問題が顕在化し始めてきました。
規模は違いますがSpotifyで起こった問題と近しいことが発生していました。
norihiko-saito-1219.hatenablog.com
これらの歴史を踏まえ、会社として成長していく上で2020年頃から新たな取り組みの必要性が高まってきました。
👻サイロ化の正体
マイクロサービスには開発のアジリティを高めるというメリットがある一方で、効果の発揮しやすいスイートスポットも存在します。
代表的なものは、開発組織やステークホルダーとのコミュニケーションコストが、アプリケーションを分割、維持するコストを上回るような場合です。
広木大地さんの記事が非常に参考になります。
成長期におけるアソビューは、アプリケーションとチーム体制、施策の一致度が高く、開発組織におけるコミュニケーションコストが最小化され、事業に対して自立自走した素早い開発の実現できました。
一方、多角化期において行ったマイクロサービス化はこのスイートスポットを超えてしまったことにより、様々な問題へと発展していきました。
具体的には以下が上げられます。
- 施策を実現する上で、チーム内でも複数のアプリケーションをまたぐため、修正コストが高い。
- 施策に対して、アプリケーションを管理しているチームが横断になってしまい、コミュニケーション/修正コストが高い。
- オーナーシップが曖昧なアプリケーションが生まれ、施策の推進難易度が上がり、最悪の場合ナレッジがない状態が発生する。また、体制変更などによりこの状態が促進されてしまう。
- 機能施策(モニタリングやセキュリティなど)のような全アプリケーションに適応が必要な修正のコストが非常に高く、チーム間での意思決定にも時間がかかる。また、1チームで対応しようとするとチーム体制を肥大化させないと対応できなくなる。
- オーナーシップのあるチームごとに技術要素が多様化し、他チームからの参入障壁が高まり、ナレッジの共有もしにくくなる。またチーム体制の変更などにより、より技術構成が複雑になりDXが低下しやすい。加えて、言語やFWのバージョンも揃わないため横断的な対応の修正コストが高くなる。
一言でいえばサイロ化ですが、アソビューではマイクロサービス化によりこのような様々な問題が発生していました。
🚀目指すべき状態
過去の歴史から見ても、チームとアプリケーションの自立性を高めることで、サービスの成長を高めることを実現してきており、この要素は今後の事業成長にも不可欠な要素でした。
一方で過度に分散された状態になると個別最適が進み、コミュニケーション/修正コスト、他アプリケーションへの参入障壁が高まっていきます。
また、どの程度の粒度になっていると自立性が高い状態なのかは、組織のフェーズにもよるため、過去の歴史、今後の事業成長、採用計画とも照らし合わせ検討する必要があります。
そのため、集約 or 分散の2択ではなく、集約と分散をコントロールすることで、個別最適と全体最適のバランスを取れる状態を目指すことが重要です。
加えて今後、もう一つ重要視していることがあります。
それは、
“個々の能力を最大化し、一人でもサービスを作り変えられるだけの大きな権限と裁量を与えること”
です。
分散を進めると、認知負荷が下がり、限られた領域の自由度と裁量を実現しやすくなります。
一方で、サービス全体で見た時に個人やチームでやれる範囲が限定され、組織内において歯車のような状態を生み出しやすくなります。
この状態は事業への共感や貢献実感が感じにくくなったり、サービスの成長を実現するために必要となる人員規模も増加しやすい傾向にあります。
アソビューではこの先も積極的に採用は継続していきますが、すぐに数百人、数千人規模の開発組織になるわけはありません。
したがって、優秀な人材が成長、活躍できる環境を作り、少数でも最大の成果を実現し、個々の力でもサービスに対してイノベーションを生み出せる状態にすることをもう一つの目的としています。
ここからは、これらの背景をもとに、実際に行っている取り組みを紹介したいと思います。
👍技術的取り組み
モノリポ：すべてを知れる
2020年頃のアソビューではGithub上に120以上のリポジトリが存在していました。
30名前後の開発組織だったため当然全貌を把握できてる人は少数で、多くの開発者は存在すら知らないリポジトリが多数存在していました。
また、そのような状態になるとルール設定が曖昧になりリポジトリの管理ポリシーも作成者や開発を行っているメンバーに強く依存する状態になっていました。
結果的に会社として担保しないといけないポリシーの維持コストが非常に高い状態でした。
そのため、まず誰でもいつでも手元でコードが確認でき、維持する必要のあるポリシーを効率的に適応できる状態を実現することにしました。
具体的にはPolyrepo(Multirepo/Manyrepo)で管理していたリポジトリ戦略をMonorepoへ移行しました。
結果的に、入社初日でも一度cloneをすればすべてのソースが手元で確認でき、コミットを開始、また必要なポリシーも一度の設定で全体に適応できる状態になりました。
更に今まで非常にコストの高かった、全アプリケーションへ行う修正も一度のコミットで実現できるようになりました。
詳細はこちらにも記載していますので、よければご覧ください。
モジュラモノリス：変更コストを下げる
モノリポ化によってリポジトリが同一になっても、別のアプリケーションに触れるための障壁が高いと思う人は少なくありません。
アジリティを高める為に一定の分散は必要になるものの、モノリスなアプリケーションのように、一度環境を構築済みであればあらゆるソースにアクセス、またデバッグできる状態はその障壁を下げるのに効果的です。
モノリスとマイクロサービスの中間的なアーキテクチャとしてShopifyでも採用されているモジュラモノリスは非常に有力な選択肢です。
分散された状態のメリットを残しつつ、横断したドメインへの迅速な変更や、新たなドメインへのチャレンジも容易になるモノリスのメリットも併せ持つため、アソビューではモジュラモノリスを中心としたアーキテクチャを活用しています。
また完全にモジュラモノリスに移行するというわけではなく、機械学習におけるPythonアプリケーション、SSOを実現するための認可サーバーなど、用途に合わせ適切なアプリケーション分割も平行して行っています。
詳細はこちらでもまとめていますので、よければご覧ください。
Protocol Buffers：迷わずアクセスできる
複数のアプリケーションに分割された状態になると、そのプロトコルによって連携のコストが大きく左右されます。
またクライアントとなるアプリケーションから見ると、外部の仕組みとなるため、どのようなインターフェイスを持つかから理解する必要があります。
アソビューではアプリケーション間の同期的な連携にgRPC、非同期連携にAmazon Kinesis Data StreamsとProtocol Buffersを利用しています。
またこれらすべてのインターフェイスは、Single Source of Truthを実現するためモノリポ内の1パッケージにまとめられており、IDLを見てアプリケーションインターフェイスを学んだり、ライブラリとして生成したSDKからすぐにアプリケーションの利用を開始できます。
これらにより、初めてアクセスするアプリケーションでも簡単かつ、特定のサーバーサイド言語に左右されることなく理解できる状態にしています。
Protocol Buffersによる開発は以下の資料にまとめていますので、興味のある方は御覧ください。
Kubernetes：同じ感覚で利用できる
モジュラモノリスを利用していても、完全に一つのアプリケーションに統合しているわけではなく、適切なアプリケーションは分割するという選択をとっています。
また、新旧の様々なアプリケーションが存在するため、仕組みや運用が違っているものもあります。
これらは立ち上げ時だけでなく、管理や運用時にナレッジの分散や全体修正など様々なタイミングでコストが発生します。
一方で今までサービスを成長させてきた原動力でもあるため、構成が違っていても迷わず素早く運用していけるようなアプリケーション実行環境としてKubernetesを利用しています。
Kubernetes(EKS)には、Namespaceのような適切な単位で権限を分離できる仕組み、Spotインスタンスによるコストの最適化、Fargateによる可用性の向上や運用コストの軽減などの機能が含まれおり、これらを活用しシングルクラスターマルチテナント方式で運用を行っています。
現在では、アソビューの大半のアプリケーションはKubernetes上で稼働しており、マニフェストファイルを理解すれば、異なるアプリケーションでもPasSのように、開発、運用が可能な状況を作っています。
API Gateway：分散を意識しない
現在アソビューでは多くの用途でAPIが使われています。
e.g. 内部API連携、外部APIの公開、SPA、アプリ
一方で、様々なサービスが立ち上がってきたため、新旧のアプリケーションが混在しており、特に外部へ公開するAPIに関しては、バックエンドが分散した状態でも、表から見ると統一したインターフェイスとして一貫性を保つ必要があります。
これらを実現するためアソビューでは、Spring Cloud Gatewayを利用したAPI Gatewayを利用しています。またこちらのAPI定義もProtocol Buffersに集約するようにしています。（詳細は別の記事で公開予定です）
これらによりAPIクライアントは、統一されたインターフェイスを利用できバックエンドが分散されていることを意識することなく利用できます。
またモノリポによりバックエンドだけでなく、フロントエンドやアプリエンジニアもすぐに変更を加えれる状態を構築しています。
😄最後に
全てではないですが、行ってきた取り組みを簡単に紹介させてもらいました！
これらはまだ道半ばの部分もありますし、まだまだやりたいことも沢山あります。
今後も集約と分散を活かし、チームそして1人1人がサービスに対して大きい権限と裁量を持ち、イノベーションを起こせる組織、技術を目指していきたいと思います。
同じような課題を持たれてる方の参考になれば幸いです。
アソビューでは、一緒に働く仲間を募集中です！
遊びを届けるサービスとして、まだまだやることが盛りだくさんです！
ちょっとでも気になる部分があればお答えしますので、気軽にお声がけください！
