ソフトウェア

NetflixやAmazonなどの大企業も導入する「マイクロサービス」の利点とは?


AmazonやNetflix、Uber、LINEなどのIT企業が導入している「マイクロサービス」は、現代の開発環境に適合したソフトウェアのアーキテクチャとして近年注目を集めています。そんなマイクロサービスの仕組みやメリット・デメリットについて、クラウドストレージサービスを提供するBackblazeが解説しています。

What Are Microservices?
https://www.backblaze.com/blog/what-are-microservices/

大規模で複雑なソフトウェア開発では長年にわたり、製品の各種サービスがそれぞれ緊密に連携する1つの大きなモジュールとして、ほとんどのコードがゼロから設計されていました。こうしたソフトウェアアーキテクチャはモノリシックと呼ばれており、長らくソフトウェア開発における主流となっていました。ところが、モノリシックでは全てのサービスが1つのモジュールとなっているため、メンテナンス性が低くアップグレードも難しいという問題があったとのこと。

これに対してマイクロサービスは、アプリケーションを構成する要素を大きな1つのモジュールとしてではなく、独立した小さなサービス群に分割・連携する手法またはアーキテクチャです。マイクロサービスでは各機能を再利用可能な単位に分割し、基本的にスタンドアローンなプロセスとして実行させ、それぞれを連携させて1つのアプリケーションとして提供する仕組みとなっています。


マイクロサービスの先駆けとして知られているNetflixは、2008年にデータベースに重大な障害が出てサービスが滞ったことを受けて従来のモノリシックなアプリケーションを再構築し、小さなサービスごとに分割されたアーキテクチャを実装しました。「マイクロサービス」という用語が浸透したのは、2014年に「Microservices」というブログ記事が公開されて以降のことであり、2008年当時はまだマイクロサービスという用語が存在していなかったとのこと。近年ではUberやAmazon、LINEなどがマイクロサービス環境でサービスを実行しており、大きな注目を集めています。

BackBlazeはそんなマイクロサービスの利点として、以下の点を挙げています。

1:コードの再利用を奨励およびサポートできる
アプリケーションを構成するさまざまなマイクロサービスについては、すでに広範なライブラリが存在しています。開発者はこのライブラリにアクセスして、必要な機能をアプリケーションに統合することが可能です。

2:論理モジュールを分離してアーキテクチャを簡素化し、信頼性を向上させられる
サービス全体をシンプルなモジュールに分割することにより、初期設計・実装・製品のアップデート・機能強化・バグ修正が大幅に容易になり、サービスの信頼性も高まります。

3:DevOpsアジャイルといった環境に適合できる
マイクロサービスでは小さなマイクロサービスを微調整するだけでサービスをアップデートできるため、開発担当と運用担当が連携するDevOpsや、トライアルアンドエラーを短期間で繰り返すアジャイルといった開発環境に適合しやすいとのこと。そのため、サービスや新機能を市場に投入するまでの時間を短縮し、継続的なアップデートを繰り返してサービスを改善し続けることが可能です。


4:本質的にスケーラブルである
Kubernetesなどのコンテナ管理プラットフォームを用いてマイクロサービスを実装することで、需要に合わせて処理能力を増減させるスケーリングフェイルオーバー、負荷分散などの処理が可能となります。

5:アプリケーションのクラウド対応に役立つ
従来のアプリケーションをクラウドに移行する場合、アーキテクチャをモノリシックからマイクロサービスに再構築しておくと、従量制課金モデルにおいてコストが削減できるとのこと。

このように、マイクロサービスには多くのメリットがある一方、「モノリシックアーキテクチャからマイクロサービスに移行するには、ソフトウェアの構築方法だけでなく、ソフトウェア開発チームの機能そのものも変更する必要がある」「マイクロサービスを導入する場合、モノリシックアーキテクチャには存在しなかった複雑性が発生する」といったデメリットもあるとBackBlazeは指摘しています。

すでにシンプルまたはモノリシックな実装で会社や顧客のニーズを十分に満たしているのであれば、あえてマイクロサービスに移行する理由はありません。むしろ、無理にマイクロサービスへの移行を推し進めれば、製品に不必要な複雑さが生じてプロジェクトに悪影響が出る場合もあります。そのため、マイクロサービスへの移行を検討するのは、アップデートや保守などに問題が生じてからがいいそうです。


また、BackBlazeはマイクロサービスをクラウドで提供する場合について、以下の点を考慮してプロバイダーを決めるべきだとしています。

1:統合/パートナーネットワーク
クラウドに移行するリスクの1つに、プロバイダーを乗り換えるのが困難なロックインの状態になってしまうことが挙げられます。1つのクラウドエコシステムに囲い込まれてしまうのを避けるため、プロバイダーのパートナーネットワークや乗り換え方法を調べておくことをBackBlazeは推奨しています。

2:相互運用性とAPIの互換性
検討しているクラウドプロバイダーがオープンなエコシステムを優先し、アーキテクチャと互換性のあるAPIを提供しているかどうかも重要です。

3:安全性
ランサムウェアやデータ破損に対する保護や、データ変更を防ぐオブジェクトロックなどの機能も、クラウドプロバイダーを選ぶ際に考慮するべきだとのこと。

4:コードとしてのインフラストラクチャー(IaC)
クラウドプロバイダーがIaCに対応している場合、プロセスを手動で管理することなく需要に合わせてストレージを拡張することができます。

5:価格の透明性
クラウドプロバイダーが提供する料金システムについて理解し、組織のニーズに合ったプロバイダーを探すことが重要だとBackBlazeは述べました。

この記事のタイトルとURLをコピーする

・関連記事
Microsoftの「マイクロサービス開発」を支援する分散アプリケーションランタイム「Dapr」がバージョン1.0に到達 - GIGAZINE

余計な「念のため」でプロジェクトが死に至る「オーバーエンジニアリング」の問題とは? - GIGAZINE

20年間ソフトウェアエンジニアとして働いて学んだ20個のことまとめ - GIGAZINE

「ITの開発現場によくいるやっかいな人」の対処法をタイプごとに解説したサイトが登場 - GIGAZINE

現役プログラマーが選ぶ「ソフトウェアエンジニア人生を変えた5冊の本」とは? - GIGAZINE

「目新しい技術」を避け「退屈な技術」をソフトウェア開発で採用すべき理由とは? - GIGAZINE

in ソフトウェア,   ネットサービス, Posted by log1h_ik

You can read the machine translated English article here.