複合システムデザイン

複合システムデザインの基礎

モノリシックアーキテクチャとマイクロサービスアーキテクチャは、ソフトウェアの設計方法における2つの異なるアプローチです。

モノリシックアーキテクチャは、システム全体を一つの一体型アプリケーションとして構築する手法です。このアプローチでは、UI、ビジネスロジック、データベースアクセスなど、システムの全ての機能が単一のコードベースに統合され、一つのデプロイメントユニットとして管理されます。

特徴としては、全ての機能が一体型で統合されているため、システム全体を一つのパッケージとしてデプロイでき、全ての機能が一緒に稼働します。しかし、モジュール間の依存関係が強く、変更や追加が他の部分に影響を及ぼす可能性があります。

モノリシックアーキテクチャのメリットとして、開発とデプロイが単純であり、システム全体を一度にデプロイできる点が挙げられます。デバッグやトラブルシューティングも比較的簡単で、小規模なシステムであれば効率的に管理できます。

一方でデメリットとして、システムが大規模になると拡張性に限界が生じます。修正やデプロイの際にはシステム全体をテスト・デプロイする必要があり、作業が非効率になる可能性があります。また、1つの部分にエラーが発生するとシステム全体に影響を及ぼすリスクもあります。

マイクロサービスアーキテクチャは、システムを複数の小さな独立したサービスに分割して構築する手法です。各サービスは特定の機能に焦点を当て、独立して開発、デプロイ、管理されます。これにより、サービスごとに異なる開発サイクルを持つことが可能となり、他のサービスに影響を与えることなく変更やデプロイが行えます。各サービスは軽量な通信プロトコル、例えばREST APIやメッセージキューを通じて相互に通信します。

このアーキテクチャの特徴として、サービスが独立しているため他のサービスに影響を与えずに開発やデプロイができることが挙げられます。また、サービスごとに分散しているため、異なるプログラミング言語やデータベースを使用することも可能です。さらに、必要に応じて特定のサービスのみをスケールアップまたはスケールダウンできるスケーラビリティの柔軟性も備えています。

メリットとしては、異なるチームが並行してサービスを開発できるため、開発効率が向上します。また、スケーラビリティが高いため、システム全体を効率的にリソース管理することが可能です。さらに、1つのサービスがダウンしても他のサービスに影響を与えないため、システムの信頼性も向上します。

一方で、マイクロサービスアーキテクチャには複雑な運用管理が伴います。複数のサービスが相互に連携するため、通信の遅延や障害に対処する必要があり、運用が複雑化することがあります。また、問題が発生した場合には、サービス間の通信や依存関係を調査する必要があり、デバッグが難しくなる可能性もあります。

まとめると、モノリシックアーキテクチャは小規模で単純なシステムに適している一方で、マイクロサービスアーキテクチャは大規模で柔軟なシステムに向いています。

ここからは以下のGithubのサイトに公開されているマイクロサービスアーキテクチャの具体的な構成例を見ながらその構成要素についてみていきます。

GitHub - aws-samples/aws-refarch-wordpress: This reference architecture provides best practices and a set of YAML CloudFormation templates for deploying WordPress on AWS.

This reference architecture provides best practices and a set of YAML CloudFormation templates for deploying WordPress on AWS. - aws-samples/aws-refarch-wordpress

https://github.com

WordPressは、PHPとMySQLをベースにしたオープンソースのブログツールおよびコンテンツ管理システム（CMS）であり、個人のブログからトラフィックの多いWebサイトまであらゆるものに使用されます。

WordPressの最初のバージョンが2003年にリリースされたとき、最新の弾力的でスケーラブルなクラウドベースのインフラストラクチャを念頭に置いて構築されていませんでした。
WordPressコミュニティの作業とさまざまなWordPressモジュールのリリースにより、このCMSソリューションの機能は常に拡大しています。

WordPressをマイクロサービスアーキテクチャの構成例として挙げた理由は、Webシステムをモジュール化し、各機能を独立したサービスとして運用することで、柔軟性やスケーラビリティを確保できる点が、マイクロサービスアーキテクチャと親和性が高いためです。具体的には、WordPressは一般的にはモノリシックな構成で提供されますが、各機能を個別に分離してマイクロサービス化することで、以下のような利点を得ることができます。

マイクロサービスアーキテクチャでは、各サービス（例: 認証、投稿管理、コメントシステム、SEO機能など）を独立したコンポーネントとして実装し、それぞれが独立して開発・デプロイ可能です。これにより、システムの一部に負荷がかかった場合でも、全体に影響を及ぼすことなく特定のサービスだけをスケールアップできるという利点があります。たとえば、WordPressの投稿やコメント機能を個別のマイクロサービスとして分け、アクセス量に応じて個別にリソースを増強することが可能です。

マイクロサービスアーキテクチャでは、各サービスが独立して開発およびデプロイできるため、開発スピードの向上と、障害発生時の影響範囲の限定が可能です。たとえば、WordPressのプラグインを一部マイクロサービスとして分離することで、特定の機能をメンテナンスする際に、他の部分に影響を与えることなく更新作業を行えます。

WordPressをマイクロサービスとして分割することで、ある機能に障害が発生した場合でも、他の機能は正常に稼働し続けます。たとえば、決済機能がエラーを起こしても、ブログ投稿や閲覧機能は影響を受けずに稼働することが可能です。これにより、システム全体の可用性を高めることができます。

WordPressをマイクロサービスに分解することで、CI/CD（継続的インテグレーション/継続的デリバリー）パイプラインを導入しやすくなります。各マイクロサービスの自動テストや自動デプロイを設定することで、WordPressの更新プロセスを効率化し、バグの迅速な修正や新機能の素早いリリースが可能となります。

このように、WordPressをマイクロサービスアーキテクチャに基づいて構成することで、システムの柔軟性、拡張性、耐障害性、運用の効率化が大幅に向上します。そのため、WordPressをマイクロサービスアーキテクチャの構成例として挙げることには、実際のWebサービス運用におけるメリットが大きいのです。

下記の図は、AWSで構成されたWrodPressの構成例です。次から各コンポーネントについて解説していきます。なお、ここでの解説では、オリジナルのドキュメントで触れられているようなAWSの各種サービスについては触れません。したがってAmazonのサービスについては全く触れないこともありますが、アーキテクチャに焦点を当てて解説したいため、割愛します。詳しく知りたい方は、リンクをたどって元の資料を参照しましょう（いっぱい解説されています）

ゲートウェイとは、異なるネットワーク間の通信を仲介する装置やソフトウェアのことです。主に、内部ネットワークと外部ネットワーク（例：インターネット）間の通信を管理・制御する役割を果たします。ゲートウェイは、ネットワーク層を超えて異なるプロトコル間のデータを変換し、通信を可能にするために利用されます。ゲートウェイの主な役割は次のとおりです。

1. プロトコル変換: 異なるネットワークプロトコル間の変換を行うことで、異なるシステムやネットワークが相互に通信できるようにします。
2. トラフィック制御: 内部と外部のネットワーク間でデータの送受信を制御し、セキュリティやパフォーマンスの向上を図ります。
3. セキュリティ管理: 外部ネットワークからのアクセスを管理し、適切な通信のみを許可します。

これを踏まえて、次に「インターネットゲートウェイ」と「NATゲートウェイ」について説明します。

インターネットゲートウェイ (Internet Gateway)

インターネットゲートウェイは、プライベートネットワーク（たとえば、VPC：仮想プライベートクラウド）をインターネットに接続するためのゲートウェイです。内部ネットワークにあるリソースがインターネットと直接通信するために必要な役割を担います。

NATゲートウェイ (NAT Gateway)

NATゲートウェイは、プライベートネットワーク内のリソースがインターネットにアクセスする際に、外部から直接アクセスされることなく通信を可能にするためのゲートウェイです。NAT（Network Address Translation：ネットワークアドレス変換）を行い、プライベートIPアドレスを持つリソースがインターネットに出るときに一時的にパブリックIPアドレスを付与しますが、逆にインターネットから内部ネットワークへの直接アクセスはブロックします。

• インターネットゲートウェイは、双方向の通信をサポートし、外部から直接アクセス可能なリソースをホスティングするために使用されます。
• NATゲートウェイは、一方向の通信をサポートし、プライベートIPアドレスを持つ内部リソースがインターネットにアクセスするために使用されますが、外部から内部リソースへの直接の接続は防ぎます。

ロードバランサー（Load Balancer）は、サーバーやサービスへのアクセスを効率的に分散させる仕組みで、Webシステムやクラウド環境において重要な役割を果たします。特に、トラフィックが一箇所に集中するのを防ぎ、複数のサーバーやリソースに負荷を均等に配分することで、システムの安定性やパフォーマンスを向上させることができます。

負荷分散

多くのサーバーを使用する環境では、すべてのリクエストが一つのサーバーに集中すると、そのサーバーが過負荷になり、システムが遅延したり、最悪の場合、サービスが停止することがあります。ロードバランサーは、これらのリクエストを複数のサーバーに分散させることで、パフォーマンスを最適化し、ユーザーに快適な体験を提供します。

可用性の向上

万が一、サーバーの一部が障害を起こしても、ロードバランサーは自動的に障害のない他のサーバーにトラフィックを振り分けるため、サービスの停止時間を最小限に抑えることができます。この機能は、特に大規模なWebサイトやクラウドベースのサービスにおいて重要です。

スケーラビリティ

システムの負荷が増加した場合、新たなサーバーを追加して処理能力を増強することが可能です。ロードバランサーは自動的に新しいサーバーにトラフィックを振り分けるため、スムーズにスケールアップが行えます。これにより、急激なトラフィック増加にも柔軟に対応できる環境を構築することが可能です。

アルゴリズム

トラフィックを分散する際、ロードバランサーは様々なアルゴリズムを使用します。代表的なものとしては、リクエストを順番にサーバーに振り分ける「ラウンドロビン」、現在最も少ない接続数のサーバーにトラフィックを送る「最小接続数」、クライアントのIPアドレスに基づいてサーバーを決定する「IPハッシュ」などがあります。また、サーバーの処理能力に応じて重みを設定し、それに基づいてトラフィックを配分する「加重ラウンドロビン」も広く使用されています。

サブネット（Subnet: Subnetwork）は、ネットワークを小さな部分に分割する技術です。IPアドレスの範囲を複数に分割し、各範囲を独立した小規模なネットワークとして扱います。異なる目的や機能を持つリソースを物理的、または論理的に分離することで、効率的なネットワーク管理が可能になります。マイクロサービスアーキテクチャでは、各サービスが異なる場所やリージョンに分散されることが多く見られます。サブネットの利用により、リソースやサービスが物理的に分離され、障害が発生しても他のサブネットに影響を与えない構成が実現します。サブネットには、主に2種類のタイプがあります：

1. パブリックサブネット: インターネットゲートウェイを介して外部のネットワーク（インターネット）と通信できるサブネット。通常、WebサーバーやAPIゲートウェイなど、外部からアクセス可能なサービスが配置されます。
2. プライベートサブネット: 外部ネットワークと直接通信しないサブネット。内部のデータベースやバックエンドサービスなど、外部から直接アクセスされるべきではないリソースが配置されます。必要な場合、NATゲートウェイを使用して外部のリソースにアクセスすることが可能です。

• Webサービスの構成: パブリックサブネットにAPIゲートウェイやロードバランサーを配置し、プライベートサブネットにはデータベースやバックエンドのマイクロサービスを配置します。このようにすることで、外部からアクセスできる部分を最小限に抑え、内部リソースのセキュリティを確保します。
• 異なる環境の分離: 開発、テスト、プロダクション環境を別々のサブネットで分けることで、それぞれの環境間でのトラフィックの混在を防ぎます。また、環境ごとに異なるセキュリティポリシーやアクセス制御を設定できます。
• コンテナベースのマイクロサービス: KubernetesやDocker Swarmなどのコンテナオーケストレーションツールを使用している場合、各サブネット内でコンテナ化されたマイクロサービスを運用することが可能です。特定のサブネット内でネットワークトラフィックを制御することで、サービス間の通信が必要な範囲に限定され、セキュリティが向上します。

WordPressアーキテクチャ全体の中でAppSubnetはWordPressアプリケーション本体が稼働しています。このアプリケーションは、コンテナベースのインスタンスで作動しており、Webサーバ（Apache）、PHP7、OPCache（PHPのスクリプトを最適化し、実行パフォーマンスを向上させるためのキャッシュ機構）がインストールされています。WordPressインスタンスはオートスケーリングによってアクセス負荷によって数を増減させることができます。このオートスケーリングはロードバランサーによって行われます。データの管理はこのサブネットではなく、後述のData Subnetによって管理されており、WordPressからデータベース（Aurora）、キャッシュサーバ（Memcache）、ファイルストレージにアクセスがあります。

Data Subnetでは、WordPressアプリケーションが必要とするデータを管理しています。キャッシュサーバ（Memcache）はデータベースに頻繁にアクセスがあるデータをキャッシュすることで、データベースへの負荷を下げており、データベースそのものはレプリケーションという仕組みを用いて、そのデータを複数のData Subnet間で同期しています。また、Webページ構築に必要なCSSやスクリプトはストレージに格納されています。このストレージは、共通のファイルストレージをマウントすることで共通化されています。

今回の授業では、モノリシックアーキテクチャとマイクロサービスアーキテクチャについて解説しました。モノリシックアーキテクチャは、システム全体を一体型で構築する手法であり、比較的シンプルな構造を持つ一方、拡張性に限界があります。一方、マイクロサービスアーキテクチャは、システムを複数の小さなサービスに分割し、各サービスが独立して開発、管理、デプロイされるアプローチで、スケーラビリティや柔軟性に優れています。

さらに、WordPressのAWS上でのベストプラクティスを例に、マイクロサービスアーキテクチャの具体的な構成についても解説しました。この構成例では、各サービスが独立してスケールでき、システム全体のパフォーマンスや信頼性を向上させる方法を示しています。

今後の授業では、これらのアーキテクチャの構成方法を段階的に学び、実際にシステムを設計・構築するスキルを身につけていきます。

今回の演習では、仮想マシンソフトの UTMを使った、OSのロードと簡単なコマンド実行をしてもらいます。

UTMは、Mac上で仮想マシンを実行するためのオープンソースの仮想化ソフトウェアです。このソフトウェアを使うことで、macOS上でWindowsやLinuxなど、他のオペレーティングシステムを仮想的に動かすことが可能です。UTMはQEMU（Quick Emulator）をベースにしており、Intelプロセッサを搭載したMacだけでなく、Apple Silicon（M1やM2）にも対応しているのが特徴です。

UTMの最大の魅力は、使いやすいグラフィカルインターフェースを備えている点です。これにより、仮想マシンの設定やオペレーティングシステムのインストールが初心者にも容易に行えるようになっています。対応するオペレーティングシステムも多様で、Windows、Linux、macOS、さらにはAndroidまで幅広くサポートしています。さらに、仮想マシンの現在の状態を保存できるスナップショット機能があるため、トラブルが発生した際にも簡単に以前の状態に戻すことができ、安心して利用できます。

すでに多くの人のMacbook Airにはインストールされていると思いますが、UTMのインストールには、homebrewを用います。万一、インストールされていない方は以下のリンクを参照してください。

Homebrew

The Missing Package Manager for macOS (or Linux).

https://brew.sh

Homebrewがインストールされている前提で、ターミナルから以下のコマンドを実行してください。

brew install utm

UTMがインストールされます。しばらく使っていないと、`brew update`などで時間がかかるかもしれません。

UTMを使うと、WindowsやLinuxなどの任意のOS（オペレーティングシステム）を仮想マシンとしてインストールすることができます。次の「仮想マシンの歴史」では、実際にUbuntuをインストールしてもらおうと思いますが、今回はすでに作成された仮想マシンをロードしてみましょう。 UTMはアプリケーション一覧から起動してください。起動が成功すると以下の画面が出ます。

この中で、「 UTMギャラリー」をブラウズというボタンをクリックしましょう。リンクが標準ブラウザで開き、以下のような画面が表示されます。

上記のサイトは、 UTMで利用可能なOSのディストリビューションが表示されています。今回は最もポピュラーなLinuxのディストリビューションの一つであるUbuntuをロードしてみましょう。画面をスクロールダウンしていくと、途中に「Ubuntu 22.04」という項目が見つかると思いますので、その画面をクリックしましょう。

画面をクリックするとUbuntu 22.04の詳細情報が表示されます。いくつか選択肢が提示されますが、その中で、「Open in UTM」を選択しましょう。

成功すると、画面がブラウザからまた UTMに戻り、以下の状態になります。仮想マシンはOS一つを内包しているので、大容量です。ここでも1時間くらいかかると表示されており、実際に1時間くらいはかかると思います。ネットワーク環境が安定しない人は、自宅で放置してロードするのが良いかもしれません。ここで時間をかけること自体はあまり意味がないのですが、本来の仮想マシンのロードやインストールにはとても時間がかかることを体感して欲しいと思いますので、あえて経験していただくことにしています。

時間がかかりますが、ロードが完了すると以下の画面になります。

左のサイドバーにあるUbuntu 22.04の項目がロード中から実行可能になっているので、実行（再生）ボタンを押しましょう。

仮想マシンの再生を放っておくと、以下のようにブートローダーで失敗します（皆さんの環境では失敗しないかもしれませんが・・）。実行中に画面をクリックして、エンターボタンなどでローディングに介入しましょう。

進むことができれば以下のログイン画面となります。ログインパスワードは「ubuntu」です。ログインしましょう。

ログインが成功すると以下のようなホーム画面になります。おめでとうございます。Ubuntu 22.04の起動に成功しました。

仮想マシンがちゃんと動作しているかを確認するため、例えば、左のアプリラウンチャーからFirefoxブラウザ（一番上）を起動して、「kdix」と検索してみましょう。

仮想マシンを起動した証明として、ターミナルから仮想マシンのネットワークインタフェースのMACアドレスを調べて、提出しましょう。ネットワークインタフェースのMACアドレスを調べるには、

ip address show

上記のコマンドをターミナル上で実行すれば良いです。ターミナルは、左のアプリランチャーから左下の「Show Applications」をクリックすると出てきます。

アプリケーション一覧の一番上の段にある「Terminal」アプリを起動すると、見慣れたターミナルが出てきますので、

上記のコマンドを実行して、その結果をGoogle Formで提出してください。

なんらかの原因でUbuntu 22.04のロードがうまくいかない人は以下の方法を試してください。

ダウンロードしたubuntu-20.04-arm64-utm.zipはダブルクリックして、解凍してください。解凍すると、Ubuntu 22.04.utmというファイルになります。

ロードが成功すると、以下のように、Ubuntu 22.04がロードされた画面になります。

残りの作業は課題で指示したものと同様です。試してみてください。