「マイクロサービスに出遅れた」ところは、先人から何を学べるか：特集：マイクロサービス入門（1）

これまでマイクロサービスアーキテクチャに取り組んだ組織の多くは、試行錯誤を重ねて、自らの組織における最適解を見いだしている。いま、マイクロサービスを考える人たちは、先人から何を学べばいいのだろうか。

» 2019年09月13日 05時00分公開

　モダンなアプリケーションを開発、運用する企業の間で、マイクロサービス化に取り組む動きが広がっている。

　こうした企業では、刻々と変化、進化するビジネスニーズに、アプリケーションが迅速に対応し続けることが求められている。また、顧客の離脱を防ぎ、逆に自社サービスへのコミットを深めてもらうためには、機能や使い勝手など、アプリケーションのユーザー体験を絶え間なく改善していかなければならない。一方で、機能やサービスプロダクトの追加、拡張にかかるコストは最小化したい。

　「疎結合された複数の『サービス』の集合体として、単一のアプリケーションを開発、運用する」のがマイクロサービスアーキテクチャだ。こうしたアーキテクチャを通じて、アプリケーションを上記のようなニーズに応えやすくすることが期待されている。

　マイクロサービスアーキテクチャは20年以上前から存在するコンセプトだが、クラウド、コンテナ、そしてこれらに関連したツールの広がりによって、以前に比べ取り組みやすくなった。また、逆に「クラウド／コンテナ時代」に適したアプリケーションの開発、運用を実現するものとしても認識され、あらためて注目されるようになってきた。

マイクロサービスで、スピードと柔軟性を手に入れる

　従来型のモノリシックな（一枚岩の）アプリケーションアーキテクチャと比べた場合、マイクロサービスアーキテクチャにはさまざまなメリットがあると知られている。

　開発では、明確なAPIコントラクトが規定されていれば、サービス単位で独立して改修や機能追加を行い、デプロイができる。モノリシックアーキテクチャのように、小さな改修でもアプリケーション全体を再構築し、デプロイしなければならないといったことが避けられる。これは、継続的／頻繁にサービスの改善や機能追加を行うようなケースに適している。

　各サービスの開発チームは、自主性を発揮し、担当サービスの改善に集中できる。サービス担当チームは並列的に開発、テストが行える。回帰テストをはじめとしたテストもしやすくなる。それぞれが他のチームを待つことなく、サービスをデプロイできる。各サービスの守備範囲は明確であり、新たに参加した開発者にとっても把握しやすい。

　原則的には、開発言語をはじめ、使用する技術をサービス間でそろえる必要はない。デプロイ時期もそろえなくていい。場合によっては、他に影響を与えることなく、特定サービスを完全に書き換えることもできる。このため、新たなフレームワークなどへの移行もより円滑になる。特定のベンダーや技術へのロックインを軽減できる効果もある。

　運用では、まず需要に応じたスケーリングがしやすくなる。マイクロサービスアーキテクチャでは、アプリケーション全体でなく、サービス単位でスケールできる。このため、より俊敏な拡張、縮小が可能で、パブリッククラウドサービスを活用している場合はリソース利用料金を抑制できる。また、原則的にはサービス単位でデータを管理するため、単一障害点（SPOF：Single Point Of Failure）の発生を回避することができる。あるサービスがダウンしても、他のサービスに影響を与えないし、サービス単位での冗長化は、アプリケーション全体の堅牢（けんろう）化につながる。

　マイクロサービスアーキテクチャでは、各開発チームが担当サービスのライフサイクル全体にわたり、運用を含めて担当し続けることになる。モノリシックなアプリケーションのように、開発プロジェクトが終了するとチームが解散するといったことはなく、メリットとしてユーザーとの距離を縮め、要望を取り入れやすくなるという点も指摘されている。

良いことばかりではないマイクロサービス

　一方、これまでプログラム内の呼び出しであったものを一部外部化するマイクロサービスアーキテクチャは、開発と運用を複雑化するというデメリットをもたらす。

　運用では、サービスの呼び出しがネットワーク経由で行われるため、アプリケーションの運用管理がより難しくなる。

　まず、ネットワークを介したメッセージのやりとり自体が遅延につながりやすくなる。また、安定的なパフォーマンスの確保および障害への備えが課題になる。さらに、アプリケーションでトラブルが発生した場合には原因の究明がより困難になる。監視／分析をきめ細かく行う必要が出てくる。

　セキュリティ対策も複雑化する。いわゆる「アタックサーフェス（攻撃対象領域）」が増大し、シークレット管理、通信の暗号化をはじめとして、個々のサービス開発チームを超えた対策が求められる。

　マイクロサービスアーキテクチャの開発では、開発チームの役割分担が従来とは異なる。モノリシックなアプリケーションでは、データベース、ミドルウェア、ユーザーインタフェースといった構成要素でチームが分かれる。一方、マイクロサービスではビジネス機能単位でサービスが分割されるため、各サービス開発チームは幅広い分野をカバーする必要がある。また、運用を含めてサービスのライフサイクル全体を担当するため、各チームの責任は増大する。

　各サービス開発チームが独立して開発、テスト、デプロイを実行できる反面、サービス単位でCI/CD（継続的インテグレーション／継続的デリバリー）パイプラインを構築する必要が生じ、構成は複雑化する。

自らにとって最適な「カタチ」を見つける旅

　上記の通り、マイクロサービスにはメリットも多いがデメリットもあり、両者は多くの点でトレードオフの関係になっている。そこで、各組織はそれぞれの指向や目標、既存の課題、アプリケーションにおけるニーズ、組織体制などに応じ、自らにとってメリットを最大化し、デメリットを最小化する最適解を見いだす取り組みをしている。また、アプリケーションによってはモノリシックアーキテクチャで、一部の欠点をカバーするアプローチを採用するケースも見られる。

　マイクロサービスアーキテクチャを推進する際の大きなテーマの一つに、「サービスの粒度」の問題がある。マイクロサービスアーキテクチャではアプリケーションを「ビジネス機能」単位のサービスに分けるということになっている。だが、具体的な分割の度合いに画一的な解はなく、同様のアプリケーションでも、組織によって分割の粒度に差が出てくる。

　粒度についての判断は、マイクロサービスのメリット、デメリットを自社としてどう評価するかに左右される。全体的なアプリケーションの規模に始まり、開発、運用についてのアジリティーをどこまで求めるか、アプリケーションの安定性、パフォーマンス、管理の複雑性について新たに生じる課題にどこまで対応できるか、必要な人員、体制をどう確保できるか、などが考慮される。段階的な試行を通じ、自組織にとって適切な粒度を見いだすことを推奨する人もいる。

　加えて、サービス間のリクエストハンドリングに関する信頼性／パフォーマンス対策をどう講じるか、分散するデータベースの管理をどうするか、運用におけるパフォーマンス管理およびトラブルシューティングや、並列的なCI/CDのための環境をどう整備するか、サービス開発チームの自由度を確保しながらどこで標準化／ガバナンスを効かせるか、そもそも人材をどう確保して割り振るかなど、数々の具体的な課題がある。

　根本的には、マイクロサービスアーキテクチャと開発、運用の体制は密接な関係にある。つまり、マイクロサービス化は組織にとって、「どのような開発、運用の在り方を目指したいか」という問いにつながる取り組みでもある。

　マイクロサービスアーキテクチャを採用する組織は、これらの課題を意識しながら試行錯誤を重ね、自らにとっての最適な「カタチ」を探求する取り組みを続けている。

　本特集では次回以降で、ECサイト「Oisix」におけるマイクロサービス化への取り組みに関する、同社開発チームの執筆による記事をお届けする。同社は、マイクロサービスという、一見きらびやかだが一筋縄ではいかないものを、どうカタチにしてきたのか。ぜひ参考にしていただきたい。

特集：マイクロサービス入門　「2025年の崖」を乗り越えるためのシステム開発の姿

複雑化、老朽化、ブラックボックス化した既存システムの残存で、2025年以降に予想される経済損失は最大12兆円／年といわれている。これを経済産業省は「2025年の崖」と呼び、企業に警鐘を鳴らす「DXレポート」を公開した。レポートでは、システム開発に取り入れるべきアーキテクチャとして「マイクロサービス」を挙げている。本特集では、マイクロサービスとは何か、システムをマイクロサービスにさせるとどのような課題が生まれるのか、モノリシックなサービスをマイクロサービスに移行させた事例などを通じて、どの場面でマイクロサービスを活用すべきか、現実解を探る。