マイクロサービス

Owned by Kohei Nishikawa
Last updated: Jul 14, 2023
49 min read

目次

概要

システム開発では、開発するシステムが、どのように使われるか、よく考えた上で設計しなければなりません。システム開発が3カ月で終わっても、運用で5年や10年使うことは普通のことであるため、設計時点で5年先10年先を見越した拡張性や保守性が求められます。

システム設計の際に、２つの考え方があります。「モノシリック」と「マイクロサービス」です。この２つのメリット・デメリットについて、見ていきましょう。「モノシリック」と「マイクロサービス」は、それぞれで要求されるプログラミングスキルが異なるため、フリーランスのプログラマであっても知っておいて良い知識です。知識があることで、仕事が増えるかもしれません。

正解はない

２つの考え方として、「モノシリック」と「マイクロサービス」があるだけで、システム設計においてどちらが正解というものはありません。正解が欲しいのであれば、結果としてその年や年度の、企業や自治体など組織としての目標が達成できれば、それが正解と言えます。A社で成功したことをB社で実践すると失敗となることがあり、お客様に合わせた設計が必要。

モノシリックアーキテクチャ

１つのサーバーに、様々な機能が集約されている。特にデータベースが１つに集約されていることは多い。

モノシリックアーキテクチャでは、システムは開発し易いが、運用段階に入ると、サーバーのスペックが耐えられる想定範囲を超えるような成長を見せた場合、ビジネス上のデメリットが多い。ビジネスを成長させようとしても、システム側に足を引っ張られる可能性がある。たとえば、「来月は10万ユーザー増やして、黒字達成！」と目標を掲げても、「今のシステムではスペックが足りないので、その目標は来年までお預けです。」というようになる。

メリット

  • 1台のサーバーに集約しているので、構成がシンプル

  • 1人で開発することが可能。

  • 必要な技術スキルが少なくて済む。複数のプログラミング言語に詳しい必要もなく、結果として安い給料で働く人材が使える。

  • 実装後のテスト範囲が小さい

  • バグをみつけやすい

デメリット

  • 機能拡張が苦手

    • 様々な機能が同居しているので、小さな機能追加であっても、他の機能に対する影響を注意しないといけない。

  • スケーラビリティ確保が不得意。１つのサーバーに集約されているため、サーバーのスペックを超えることはできない。

    • たとえば、ECサイトやゲームで急なアクセス増加で、サーバーがダウンし、なにも出来なくなる。

  • 信頼性確保が困難。１つのサーバーにまとまっているため、1つの機能不全が全体に波及し、復旧に時間を要する。

    • ECサイトやゲームであれば、ビジネスが1日でなにもかも終わりになるかもしれない。

  • 開発に用いたフレームワークやライブラリのバージョンアップのために、全機能の検証が必須で、規模が大きくなるほど、時間がかかる。

    • たとえば、個人情報漏えいバグを修正するために、サービスを停止した状態で数カ月かかる可能性がある。

  • 機能追加時や機能削除の際に、再起動が必要となる。

    • たとえば、ECサイトやゲームであれば、誰も利用しない時間を設ける必要がある。

マイクロサービスアーキテクチャ

物理あるいは仮想サーバー、サーバレスなどを用い、APIを使ってつながっている形態。図のように複数のプログラミング言語やMySQL、PostgreSQL、MongoDB、CockroachDBなど、目的と用途に応じた様々なデータベースが混在する。

マイクロサービスアーキテクチャでは、APIでつながっていることで、機能拡張がモノシリックアーキテクチャに比べて容易である。ビジネス視点でシステムを考える。

メリット

  • ビジネス側のリクエストに対応しやすい。

  • 機能などに合わせて、様々な言語を使うことができる。モノシリックアーキテクチャと違い、JavaとPHPを混在して使うなど可能。

  • 機能拡張に優れる。柔軟性がある。

  • APIでつなっているため、ある機能がダウンしても、他の機能は存続できることから、信頼性が高い。

  • １つのサーバーに集約していないため、スケーラビリティに優れる。

  • 各機能が別々に分かれていることで、保守しやすい。

デメリット

  • モノシリックアーキテクチャに比べてシステムが複雑になる。

  • 複数のサーバー(物理、仮想、サーバーレス)で構成されるため、インフラコストが高くなる。

  • 開発者が複数となり、また開発チームが多様化することで、設計の共通化などのためにコミュニケーション、共通の言葉の辞書が必須など、コミュニケーションコストが高い

  • 複数のプログラミング言語、様々なデータベースが混在するため、バグの発見が難しくなる。

その他

  • 機能拡張を考慮すると、ETL等のデータ連携ツールやAPI Gatewayをハブ(中継)にした方が良い。ローコードプラットフォームでエンドユーザー(アプリケーション利用者)が使うUI(ユーザーインターフェース)を作成する手もある。

    • データ連携ツールを使う場合は、データ型や値を別のフォーマットに変更することができる。

    • ETL等のデータ連携ツールとローコードプラットフォームを同時に利用するなど、図で表示した構成以外に、互いに組み合わせても良い。このあたりは、設計するシステムに合わせて組み合わせる。

モノシリックからマイクロサービスへ

１つのサーバーにEC(通販サイト)サーバーとグループウェアが同居するような複数のアプリケーションが含まれる場合は、各アプリケーションごとにサーバーを分割し、APIを通じて１つのまとめるところから始める。

サンプルアプリケーション「Sock Shop」で確認するマイクロサービス

概要

マイクロサービスのサンプルとしてよく取り上げられる「Sock Shop」を使います。その名のとおり、靴下のECサイトのサンプルです。ECサイトの見本として使っても良いですが、もっとも重要なことは「API」と「コンテナ」で構成されていることです。マイクロサービスで「API」が重要であることは既に述べています。「コンテナ」を多く用いることで、以下の利点があります。

  • 支払いや顧客情報管理などの各機能をコンテナとして、切り分けることで

    • なにかしらの機能で障害を起こした際に、問題を切り分けやすい。

    • 個別に開発できる

      • モノシリックアーキテクチャでは、すべての機能が、特にデータベース(DB)が１つであることから、「あちら立てればこちらが立たぬ」となり、結果として、たった１つの機能を追加するために全体を調整しながら追加開発しなければならないため、開発が長期化することがあります。

    • 必要に応じて、一部の機能だけバージョンアップができる。

      • モノシリックアーキテクチャで、一斉にバージョンアップすると、一部で問題が起きたときに全てのバージョンアップを中止しなければなりません。そうなると、たとえば個人情報漏えいのためのセキュリティ対策を行うためのバージョンアップが中止となり、セキュリティ対策が行えないまま運用し続けることになります。

    • 障害時の復旧が早い

Sock Shop のGithubレポジトリ

https://github.com/microservices-demo/microservices-demo

Sock Shop についてのドキュメント

https://microservices-demo.github.io/docs/index.html

Dockerでサンプルアプリケーション「Sock Shop」の起動（必須）

ローリングアップデートが不要であれば、Dockerでコンテナ運用することは考えられます。

マイクロサービスの定番サンプルアプリケーション「Sock Shop」のDocker Compose版を起動してみましょう。ここでは、Docker ( Docker Engine )とDocker Compose がインストール済みとします。まだ構築していない場合は、Dockerによるコンテナ体験のDockerのインストールとDocker Composeのインストールを行ってください。

ホームディレクトリに移動

作業のため、ログインしているユーザーのホームディレクトリに移動します。たとえば、ユーザー名がuser1 の場合は次のようになります。実際の各自のユーザー名に読み替えてください。

cd /home/user1

docker-compose.yml の取得

次のコマンドを実行します。

git clone https://github.com/microservices-demo/microservices-demo.git docker-microservices-demo cd docker-microservices-demo/deploy/docker-compose/

Sock Shopの起動

次のコマンドを実行します。

docker compose -f docker-compose.yml up -d

上記は、Docker Composeのインストール時に、apt を使ってインストールした場合です。スタンドアロンタイプの場合は、docker-compose となります。

実行結果

起動確認

次のコマンドを実行します。

実行結果

Webブラウザで確認

Webブラウザで、VMに割り当てているIPアドレスを用い、http://Docker環境を実行中のVMのIPアドレス (例 http://192.168.127.10 )にアクセスする。VirtualBox上の仮想マシンの場合は、仮想マシンにホストオンリーアダプタを割り当てた状態で、「 ip a 」コマンドを実行し、「enp0s8」に表示されたIPアドレスを使う。

画面右上の「Login」を使いたい場合は、以下のユーザーアカウントでログインできる。

  • ユーザー名 user / パスワード password

  • ユーザー名 user1 / パスワード password

Sock Shop 中身を可視化する

前述の『Dockerでサンプルアプリケーション「Sock Shop」の起動』の続きとして、Weave Scopeを使って、コンテナがどのように使われているかを可視化します。

Weave NetおよびWeave Scopeのインストール

次のコマンドを実行します。

Weave ScopeとWeave Netの起動

Weave Scopeの起動

実行結果

Weave Netの起動

起動確認

実行結果

Webブラウザで、Weave Scope にアクセス

Webブラウザで、VMに割り当てているIPアドレスを用い、http://Docker環境を実行中のVMのIPアドレス:4040 (例 http://192.168.127.10:4040 )にアクセスする。チャート(グラフ)が表示されます。

画面右下で、下記を選びます。選択肢を変えることもできます。各コンテナがどのような関係にあるか、チャート(図)で確認することができます。

  • 一段目：All

  • 二段目：Running Containers

  • 三段目：Show uncontainerd

また、画面上部で、「by DNS name」や「Containers」をクリックして切り替えてみましょう。表示が変わり、複数の視点で、サンプルアプリケーション Sock Shop の構成を見ることができます。

画面上部の表示で、「Table」をクリックします。コンテナの稼働状況をモニタリングすることができます。「Resources」を選べる場合は、ホストごとのリソースを確認できます。「Graph」をクリックすることで、チャート形式の表示に戻ります。

「Resources」をクリックした場合は、ホストごとのリソース状況を表示

Docker Compose で起動したコンテナ（Sock Shop関連コンテナ）の停止

次のコマンドを実行します。

実行結果

Docker Compose で起動したコンテナ（Sock Shop関連コンテナ）の削除

次のコマンドを実行します。

実行結果

その他のコンテナの稼働状況を確認

次のコマンドを実行します。

実行結果

Weave関係のコンテナが動いていることがわかります。

Weave関係のコンテナの停止と削除

コンテナの停止

次のコマンドを実行します。前述のコンテナ稼働状況で確認した、4つのWeave関連のコンテナを停止。「weavevolumes-2.8.1」は数字が異なることがあるので、docker ps - a でコンテナの状況を確認することが重要。

実行結果

コンテナの削除

コンテナ停止を実行した際にコマンドで、stop を rm に変えるだけ。

実行結果

コンテナの状況を確認

次のコマンドを実行します。

実行結果

コンテナがなくなり、きれいさっぱりとなった。

Kubernetes環境で、サンプルアプリケーション「Sock Shop」の起動（任意）

仮想マシンの割当メモリが、8GB程度必要。また、プロセッサの割当CPU数も、２つ以上とすること。

ホームディレクトリに移動

作業のため、ログインしているユーザーのホームディレクトリに移動します。たとえば、ユーザー名がuser1 の場合は次のようになります。実際の各自のユーザー名に読み替えてください。

Kubernetes環境の構築

microk8sによるkubernetes環境の作成

microk8sのインストール

microk8sのグループに、作業中のユーザーを登録

kubernetesの設定ファイルがあるディレクトリへのアクセス権限を付与

ログアウトして、再度SSH接続を実施。GUI導入済みのLinux環境の場合は、再起動すること。

microk8s の起動状況を確認

実行結果 << 有効化 / 無効化 中のアドオン情報も表示される。「high-availability: no」となっていることから、シングルノード構成を示している。

kubectl のエイリアスを作成 ( microk8s 特有の設定 )

次のコマンドを実行

実行結果

microk8s アドオンのうち、DNSとIngressを有効化

次のコマンドを実行

実行結果

サンプルアプリケーション「Sock Shop」の起動

git コマンドを実行できる必要がある。

インストール済みの人は、次へ。不安場合は、git のインストールを実行。

インストール済みの場合は、次の結果が出力される

マイクロサービスデモ「sock shop」の取得

kubernetes namespaceの作成

起動用のファイルがあるディレクトリに移動

ls コマンドを実行することで、起動用のファイルが存在していることを確認できる。

complete-demo.yaml を使って起動

実行結果

起動(デプロイ)したPodを確認

実行結果

起動(デプロイ)したsvc(service)を確認

実行結果

front-end にアクセスする。Webブラウザで、VMに割り当てているIPアドレスを用い、http://kubernetes環境を実行中のVMのIPアドレス:30001 (例 http://192.168.127.10:30001 )にアクセスする。APIアクセスする場合は、このURLが、ベースURLになります。

画面右上の「Login」を使いたい場合は、以下のユーザーアカウントでログインできる。

  • ユーザー名 user / パスワード password

  • ユーザー名 user1 / パスワード password

「Sock Shop」の仕組み

中身をチェックするにあたり、jq コマンドを有効化します。jqコマンドを使って、JSONデータを見易くします。

Sock Shop では、swaggerドキュメントが用意されているので、APIドキュメントが公開されていますので、API を見てみましょう。

https://microservices-demo.github.io/api/index.html

ベースURL

http://kubernetes環境を実行中のVMのIPアドレス:30001 (例 http://192.168.127.10:30001 )

商品カタログ情報をAPI取得

次のコマンドを実行

例 curl -s http://192.168.127.20:30001/catalogue | jq .

実行結果

顧客情報をAPI取得

次のコマンドを実行

例 curl -s http://192.168.127.20:30001/customers | jq .

実行結果

カード情報をAPI取得

次のコマンドを実行

例 curl -s http://192.168.127.20:30001/cards | jq .

実行結果

顧客情報のカード情報に、card (カード)情報のhrefの値と同じものが入っているので、「sock shop」では、顧客情報のAPIとカード情報のAPIがつながっています。

microk8sの停止と再稼働

次のコマンドを実行することで、お使いのmicrok8s環境について、停止と再稼働を行うことができます。

停止する場合

停止後、再稼働する場合

microk8sの初期化

次のコマンドを実行することで、お使いのmicrok8s環境が、microk8sのインストール直後の状態に戻ります。

実行結果

microk8sのアンインストール

次のコマンドを実行することで、お使いのmicrok8s環境が削除されます。

実行結果

ハンズオン(実習)

サンプルアプリケーション Sock Shop (必須)

サンプルアプリケーション「Sock Shop」で確認するマイクロサービスで説明している内容について、下記を実施しましょう。

  • 『Dockerでサンプルアプリケーション「Sock Shop」の起動』の手順を１つ１つ実行し、Wave Scopeを使って、コンテナの構成を見る。

任意

  • 『Kubernetes環境で、サンプルアプリケーション「Sock Shop」の起動』の手順を１つ１つ実行し、Sock Shop のAPIから、API が互いにつながっていることを確認する。

ノーコード・ローコードプラットフォームで、マイクロサービスを作ってみよう(任意)

ToolJetやNode-REDを使って、複数のAPI を束ねたサービスを作ってみよう