N予備校のマイクロサービス - ドワンゴ教育サービス開発者ブログ

N予備校のバックエンドは、2016年のリリース当初からマイクロサービスアーキテクチャを採用しています。

この記事では、N予備校のマイクロサービスアーキテクチャについて、主にアプリケーション側の観点からご紹介していきます！

N予備校の全体構成

なぜマイクロサービスにしたか？

はじめに、マイクロサービスアーキテクチャを採用した理由に触れておきます。

マイクロサービスの大きなメリットとして、各マイクロサービスごとに並行して・集中して開発することで、大規模で複雑なアプリケーションも迅速かつ頻繁にリリースできるというものがあります。

N予備校でも初期リリースに向けた開発で、以下のようなところがマイクロサービスアーキテクチャの利点にマッチしていたため採用されました。

そもそも機能ごとに開発チームが別だった => 組織構成に合わせたサービス構成がマッチしていた
リリースに向けて短い期間で一気に開発する必要があった => 多人数の並行した開発で、小さなプロダクトに集中することでスピードが出せた
サービスによっては、社内の別サービスからも使われていた => 別サービスから使われる箇所をN予備校ドメインから切り離し1つのサービスとして開発した

リリース後にバックエンドチーム自体は1つになりましたが、マイクロサービスアーキテクチャの利点を生かして、チーム内でも並行して開発し、何度かあった大規模な機能拡張も無事達成してきました。

採用しているマイクロサービスのデザインパターン

それでは、N予備校のマイクロサービスの構成について、microservices.ioのマイクロサービスアーキテクチャを参照しながら説明します。

Decomposition/サービスの分割

N予備校では各マイクロサービスを機能ごとに分割しています。microservices.ioでは Decompose by subdomain のパターンです。

N予備校のサービス全体図を以下に示します。

2021/8時点ではN予備校のバックエンドは10個のマイクロサービスで構成されています。以下に詳細を説明していきます。

N予備校の各メイン機能に対応するマイクロサービスとして以下のように分けています。

教材は「教材管理」「問題採点」（図の紫色の部分）
授業は「授業管理」「双方向通信」（図のピンク色の部分）
フォーラムは「フォーラム管理」

他は全体に関わる機能として以下があります。

さまざまな機能を利用するための「ユーザー情報管理」「通知・お知らせ管理」「メディア基盤」
裏側を支えるものとして「タグ管理」
これらを統合してクライアントに提供する機能として「API Gateway」

余談ですが、各マイクロサービスの社内コードネームは学問の神様をはじめとした知識・学問に関係するものです。（図の中にコードネームのヒントがあります）開発陣一同、各マイクロサービスを親しみをもって呼んでいます！

授業のライブ配信に関しては、Wowzaを利用しています。

ドワンゴ社内の他チームとの連携もあり、課金機能やスマートフォンアプリへの通知などについてはニコニコ動画でも利用されている社内基盤を利用しています。また、N高等学校・S高等学校の教務システム(教職員が利用する管理システム)とも生徒の進捗情報などを相互にやりとりしています。

Data management/データ管理

データの管理方法は、マイクロサービスそれぞれがデータベースを持つ、Detabase per Service のパターンを採用しています。

それぞれの責務を達成するために必要なデータは各マイクロサービスが管理しています。データベースは基本的にはリレーショナルデータベース(PostgreSQL)で、メディア基盤マイクロサービスのみAWS Dynamo DBを使用しています。

External API/外部API, Orchestration/オーケストレーション

外部に向けたAPIの設計は、API Gateway を採用し単一のマイクロサービスがその責務を担っています。PC, N予備校のスマホアプリ, VirtualCastアプリなど、すべてのクライアントが１つのエントリーポイントを使用しています。

またAPIの実装のためのデータのオーケストレーションとしては、API Composition で行っています。API Gatewayの責務を担っているマイクロサービスが、API Composerとしても実装されています。 API ComposerがN予備校サービスとしてのキャッシュの仕込み/削除も行っています。

例として、ユーザーがiPhoneで授業を閲覧したいと思った場合の流れを示します。

このようにAPI Gatewayマイクロサービスが他のマイクロサービスから必要な情報を集めクライアントに提供することで、生放送授業が閲覧できます。

Communication/コミュニケーション

マイクロサービス間のコミュニケーションは、API Gatewayマイクロサービスからの問い合わせという形の同期的な取得がメインです。 パターンとしてはRemote Procedure Invocation (RPI)で、REST(HTTP)で実現しています。

マイクロサービス間の依存関係は、オーケストレーションレイヤーからの一方通行です。具体的には、API Gatewayマイクロサービスから教材管理マイクロサービスへのデータ取得はありますが、逆は同期的には行いません。

では、教材管理マイクロサービスでデータ変更がありAPI Gatewayマイクロサービスに通知したい場合はどうしているかというと、非同期でコミュニケーションを行っています。パターンとしてはMessagingとして、Publish/Subscribeの仕組みを使います。さらに具体的にいうと、AWS SNS/AWS SQSの組み合わせを利用しています。

Deployment/デプロイ, Service discovery/サービスディスカバリ

それぞれのマイクロサービスはコンテナ化され、ビルド及びデプロイはそれぞれのマイクロサービスで行います。パターンとしては、Service instance per containerです。各マイクロサービスはDokcerコンテナイメージとしてビルドし、コンテナ化されたアプリケーションを実行するためにKubernetesを使用しています。

サービスディスカバリは、 Server-side service discovery パターンです。外部からの問い合わせに対してはAWS ALBを利用しています。

利用しているフレームワーク/サービス

それぞれのマイクロサービスごとに異なる技術スタックを採用できることはマイクロサービスアーキテクチャの利点の1つです。

以下に利用しているフレームワーク/サービスを具体的に紹介します。

Ruby on Rails/Ruby: 7個のマイクロサービスで使われています。リリース当初のエンジニアのスキルセットや、迅速にサービスを提供できるメリットがマッチしていたため採用されました。
Padrino/Ruby: ユーザー情報マイクロサービスで使われています。単機能のマイクロサービスであることからRuby on Railsでは過剰であり採用されました。
Express,socket.io/Node.js: 双方向通信マイクロサービスで採用されています。WebSocketの取り扱いについてイベント駆動なアーキテクチャが求められていたことや速度を重視して採用されました。
AWS Lambda/Node.js: メディア基盤マイクロサービスに採用されています。配信自体は Amazon S3とAmazon CloudFrontを使用して行っています。

マイクロサービスの運用の難しさと今後の展望

N予備校では2016年のリリース当初から5年間、この構成を運用し続けてきました。

メインユーザーであるN高/S高の発展もあり、ユーザー数は大きく増えました。また、リリース当初に考えていた以上にさまざまな企画が発案され、サービスの拡充に伴い要件は変わり続けています。

その中でもマイクロサービスアーキテクチャの強みを活かしてスピードを重視して開発してきました。その一方で、抱える課題も大きくなってきてしまいました。

ここでは、マイクロサービスアーキテクチャに付随するN予備校バックエンドが抱える課題の中で最も大きなものと今後の展望についてご説明します。

課題: 責務の分割へのハードル

変わり続ける要件に対して、当初の設計も変更しなければいけません。それをどう対応させるかは、個人的には新規開発以上に頭を悩ませる要因が多いと感じています。

要件が増えれば、サービスの持つ責務も増えます。マイクロサービス構成の場合には、新しいマイクロサービスの定義が必要になってきます。

しかし、マイクロサービスを新規に作るためにはいくつか超えなければいけないハードルがあります。

マイクロサービス間を密にしないためには既存のマイクロサービスの責務から似たものを括り出し新マイクロサービスを定義する。
新マイクロサービスを立ててアプリケーションレイヤーを初期設定する。
SREと協力してインフラ面を準備する。

リリース前の開発と異なりチームも分割されているわけではないので、目先に関してだけで言えば上記はコスト増に見えてしまいます。

結果として、データを集約しやすいマイクロサービスを拡張することで機能を実現しました。

具体的なケースを紹介します。リリース後の一番大きな変更は、N高/S高の必修授業(高校卒業資格を得るための動画やレポートなどのコンテンツ)がN予備校で受講できるようになったことです。また、今年の4月から始まったN高/S高の普通科プレミアムでのVR教材の提供も始まっています。

どちらのプロジェクトでも「認可」と「教材」の2点で大きな設計変更が入りました。

その設計変更をスピード感をもって開発できたこと自体は、元がマイクロサービスだったからではあるのですが…。扱うものがリリース時と比べ物にならないぐらい多くなった結果、コードが肥大化・複雑化してしまいました。

今後の改善方針

成長し続けるサービスを支えるバックエンドチームとして、今後もスピード感を持って開発していくことは私たちの使命です。

しかし、リリースから5年経ち、上記の責務の肥大化・複雑化は私たちのアジリティを低くする要因になってきています。

そこで、まずは腰を据えて設計を見直しています。

2021年8月現在、教材管理マイクロサービスを中心に責務を見直すプロジェクトが動いています。認可の責務のあり方や多様な教材への拡張性をベースの課題として、どのような設計がよいのかを議論している真っ最中です。新設計ではゼロベースで最適な思想から議論を始め、マイクロサービスの用途に即した新言語/新FWの導入も検討しています。

また、組織としてチーム構成の見直しも今後予定しています。

リリース前は各マイクロサービスに分かれてチームが構成されていましたが、リリース後5年間は1つのチームですべてのマイクロサービスを見ています。どうしても広いマイクロサービスの知識が必要になるとアジリティが落ちてしまいます。より集中して開発ができるように、マイクロサービスごとのチーム構成にするなど組織の点からの改善も行っていく予定です。