エンジニア勉強会レポート｜巨大モノリシックシステムのマイクロサービス化はどうやって実現するのか。技術選定のポイントからアンチパターンまで

近年、システムの柔軟な開発を実現するアーキテクチャとして注目を集めているマイクロサービス。

マイクロサービスとは、複数の独立した機能を組み合わせて1つの処理を実行するアーキテクチャである。従来型の仕組みでは、大きな単一の機能により1つの処理を実行するが、マイクロサービスでは機能を複数に分けることで、機能ごとの最適な技術選定が可能になる。また、マイクロ化によって各機能間の影響を減らすことができ、新たなシステムを導入する際の開発工数の削減が可能だ。

2021年1月13日、すでに社内システムのマイクロサービス化を始めて1年が経過した株式会社プレイドと、現在マイクロサービス環境へ移行計画中のレバレジーズ株式会社が、オンラインの合同勉強会を開催。実際の導入事例や移行計画の紹介を通して、マイクロサービス化を実現する技術の選定理由や、移行の際に発生する課題についてなどが語られた。

• keyboard_arrow_down セッション1：マイクロサービス環境への移行データにトランザクションIDを付与し、データの不整合に対応
• keyboard_arrow_down セッション2：マイクロサービスで快適な開発環境を実現したのは「Tilt.dev」
• keyboard_arrow_down セッション3：「gRPC・gRPC-Web」「CDK」「AppMesh」。3つの技術で開発・運用効率をアップ
• keyboard_arrow_down セッション4：マイクロサービス環境への移行計画策定に役立つアンチパターンを4選
• keyboard_arrow_down 登壇者コメント｜初めてのオンライン合同勉強会を終えて

レバレジーズ住村からは、マイクロサービス化予定のサービス構成やシステムの粒度、既存サービスからの移行計画中に出てきた課題について語られた。

レバレジーズはレバテックの求職者向けサイトと社員用営業管理サイトをマイクロサービス化する予定だ。マイクロサービス化にあたって、「機能」と「データベース」2つの視点でシステムの粒度を検討している。機能の粒度について簡単に説明すると、例えば、レバテックキャリアで求職者から応募があった際の「応募」に関連するシステムの処理を「機能」としている。

住村によれば、あらゆる機能やデータベースをすべてマイクロサービス化すると非常に工数がかかることから、まずは課題が明確になっている機能に限定して最適化を予定しているとのことだ。また、データベースの移行については、テーブルの正規化が可能な部分に限定し、移行を予定している。正規化が可能なテーブルというのは例えば、複数の意味が混在しているが単語の粒度をそろえられるテーブルや、数値系の情報を管理しているマスタ項目のテーブルだ。

移行の際、レバレジーズでとくに課題となっているのは、既存システムのデータベースとマイクロサービスのデータベース間で、移行時の連携中に発生すると予想されるデータの不整合だ。現在は、不整合を避けるために、連携するデータにトランザクションIDを付与することで、データベースからデータを見分ける対応を予定している。ただ、データベース間の連携はネットワークを介して行うため、通信トラブルなどの物理的な問題の発生が予想される。そのため出来る限りデータベース間の連携を減らして移行する方法を検討しているとのことだ。

マイクロサービス化をするとシステムの数が増え、多くの開発環境を用意する必要があるので、環境構築の手間や運用時のコストを下げる必要がある。プレイドの大矢氏からは、実際にプレイドが採用している、快適な開発環境を実現したインフラ構成について語られた。

プレイドではマイクロサービス化以前、Docker Composeを用いてローカルのMacPCで開発を行っており、既存の環境のままマイクロサービス環境に移行すると下記の問題が発生することがわかっていた。

• ・Docker for Macの動作が遅く、マシンのリソース不足が発生する
• ・開発環境（Docker Compose）と本番環境（Kubernetes）で設定が異なる

対策として、ローカルマシンのリソース不足に対しては、ローカル環境の開発からリモートインスタンスの開発に移行することで解決を試み、環境の違いに対しては、開発環境をDocker ComposeからKubernetesにすることで問題の解決を行ったとのことだ。

開発環境でのKubernetes導入や、リモートインスタンスによる開発を実現するため、プレイドではTilt.devによる開発環境構築を行ったとのこと。Tilt.devはローカルでコンテナを立ち上げず、ローカルのファイルを更新したら自動でリモート先のKubernetesにファイルの内容を同期する仕組みだ。

また、プレイドでは本番環境に近い開発環境を構築するため、工夫をしていることがいくつかあるそうだ。例えば、本番のKubernetes manifestにパッチを当てることで、開発用に別途manifestを書く必要をなくしている。これにより、KubernetesAPIを開発環境でも使えるようになったとのことだ。

リモートインスタンスでローカルのファイル変更をすぐに確認できるかについては、一度環境を立ち上げてしまえば、その後は素早く作業可能だそうだ。ただ、最初の立ち上げ時には短くて2分、長くて7分ほどの時間がかかる。今後は、開発環境の初回起動時間の短縮や、リモートインスタンスでKubernetesを使用する際のコスト削減が課題になるとのこと。

レバレジーズ竹下は、マイクロサービス環境における、開発効率・運用効率の両方を高めることを目的としたインフラ技術の選定について語った。

現在、レバレジーズでマイクロサービス化を進めるにあたり採用する予定の技術は、「gRPC・gRPC-Web」「CDK」「AppMesh」の3つ。技術選定の観点としては、gRPC・gRPC-Webはコミュニケーションコストの削減、CDKはベストプラクティスの共有、AppMeshにおいてはアプリ開発とインフラを切り離すことにより、開発に注力できる環境の構築を目的としたとのことだ。

gRPCとはGoogleの開発したRPCプロトコル。これまでのレバレジーズの開発では、はじめにAPI設計者のポジションを設け、その設計者が作ったAPI設計書をもとに開発を行っていた。この従来の方法では、システムが完成しないと制作物の確認をできない、仕様書の影響範囲が大きいため仕様書を変えづらいなどの問題がある。

gRPC・gRPC-Webを採用することによって、これらの問題が解消されることに加え、レバレジーズのシステム開発スタイルは大きく変わるそうだ。新しい手法では、gRPC・gRPC-Webのインタフェース記述言語IDLを用いる。IDLを用いた開発をすることで、最終的に各エンジニアが自分の開発領域のAPI設計者となり、仕様を変更する際は自分の領域のIDLを修正することになる。これにより、全体の仕様書を意識する労力を減らすことに加え、コミュニケーションコストを減らすことにもつながる。デメリットとしては、新しくIDLの知識が必要になること、担当している人がAPIを定義するので設計スキルが必要になることの2点が挙げられた。

2つ目に採用した技術はCDKだ。CDKはAWSでしか使用できない機能で、AWSのリソースをプログラミング言語を用いてデプロイすることができ、TypeScript、Python、Javaなど様々な言語に対応している。

レバレジーズでは共有ライブラリを用意し、Builderパターンによりベストプラクティスを適用したAWSのリソース配分を構築できるようにしている。各マイクロサービスは、最小限の設定でベストプラクティスに沿った実行環境を、簡単に構築可能とのことだ。

3つ目はAppMeshだ。AppMeshでは、ログ収集、通信モニタリングなどのビジネスロジックに関係のない機能をアプリから分離することができる。それにより、アプリ開発者がアプリ開発に集中できる状態を作り、開発効率を上げることを目指している。本格的な導入を今後予定しているが、現在採用事例が少なく、さらにgRPC環境での採用はさらに少ないため、参考になる資料がない状況とのことだ（2021年1月現在）。

プレイドの山内氏から、マイクロサービス化をする際のアンチパターンについてが語られた。今回発表のあったアンチパターンはオライリーの「Microservices antipatterns and pitfalls」から4つを引用したもので、プレイドでの実際の体験談と併せての発表となった。

• アンチパターン1「データを先に移行するな」

まずはデータ移行の順番について。データを移行する際は、機能の移行を先に行い、データの移行は後にするとのことだ。データはスキーマを含めて密に結合しやすいため、分離のしやすいフロントエンドから移行をする。そうすることで、既存の機能にあまり影響を与えることなく移行を行うことができ、一番大きなデータベースの問題に、時間をかけて取り組むことができるそうだ。

• アンチパターン2「レポート作成機能がサービスを跨っている」

このアンチパターンは、非同期イベントプッシュを使うことで解決できるとのことだ。レポート機能は複数のサービスからデータを抽出していることが多く、メインの機能ではないため手を出しづらい状況となっていることが多い。そういった場合、非同期のイベントプッシュを使うことで、各サービスの内部でレポートを作らず、レポートを出力するためのイベントデータを非同期で出力を行い、機能の分離を行う。プレイドでは一部のレポートデータをBigQueryにまとめることで、データがサービスを跨いでいることにとらわれずレポートを出力することができているとのことだ。

• アンチパターン3「コントラクトのバージョン管理をしていない」

コントラクトとは簡単にいうとAPIの仕様のことである。解決する方法は2つあり、1つ目はバージョン番号をリクエストヘッダーに入れて対応する方法で、2つ目はバージョン番号をリクエストスキーマに入れる方法とのことだ。そうすることによって、コントラクトのバージョンをソースコードに直接ハードコーディングするようなことがなくなり、柔軟にバージョン管理をできるようになる。

• アンチパターン4「マイクロサービスの粒度が細かすぎる」

解決方法としては、「サービスのスコープと機能を分析する」「データベーストランザクションを分析する」「サービスのコレオグラフィーを分析する」の3つとのことだ。どれか1つに対応するというよりは、すべての分析をする必要があるそう。プレイドでは適切な粒度を導き出すため、チームの境界とサービスの境界を合わせるという方針をとっている。また、組織によってアーキテクチャが決定されるのを避けるため、アーキテクチャを定めるための組織を作るなどの対応をしているとのことだ。

オンラインでの他社を交えた合同勉強会は、レバレジーズ、プレイド両社にとって初めての試みであった。開催を終えて、両社の登壇者にオンライン合同勉強会への感想を聞いた。

• レバレジーズ株式会社住村氏

一口にマイクロサービスと言っても、背景も採用している技術スタックも異なるため学ぶことが多かったです。また、自社で抱えている課題の解決策になる情報やパターンも知れたので、今回は本当に参加できて良かったです。オンラインだと開催のハードルも低いと感じたので、社外の方との勉強会は今後も積極的に続けていきたいと思いました。

• 株式会社プレイド大矢氏

マイクロサービスについて他社のエンジニアの方の発表を聞いたり、ディスカッションしたりするのは非常に学びになりました。住村さんの発表では、マイクロサービスの様々な分割方針のメリットデメリットについて知ることができました。分割の粒度をどうするかは難しい問題だと感じていますし、住村さんもとても悩んでいるというのが伝わりました。竹下さんの技術選定に関する発表も勉強になりました。IDLについてはプレイドでもちょうど導入したところでしたが、組織が違うと導入の背景も少し異なっていて面白かったです。

• レバレジーズ株式会社竹下氏

初めてのオンライン勉強会を無事に開催できて良かったです。実際にマイクロサービスを開発するに当たっての実践的な内容を知ることができたので、個人的にはかなり有意義な勉強会になったかなと思います。

• 株式会社プレイド山内氏

社外も含めた、完全オンラインの勉強会運営は初めてでしたが、大きなトラブルもなくスムーズに進められたのは良かったと思います。住村さんの課題が偶然にも自分の発表した内容で解決できたりしたので、勉強会で発表した意義がありました。