はじめに

IT業界で仕事をしてると、どこかで絶対耳にする「アーキテクチャ」。
そんなアーキテクチャにはいくつか種類があるようですが、今回は先輩エンジニアに教わったWEB三層アーキテクチャを取り上げて記事にしています。

例に挙げるAWSアーキテクチャ図を頭に入れておけば、どのシステム構成を見ても大体は理解できるのではないかと思います。

聞いたことはあるけど内容はよくわからない、そんな方に読んでいただけると幸いです。

アーキテクチャとは

直訳は「建築様式」。
例えば、不動産で考えたとき、おおよその間取りというのはどの家もそんなに変わらないはずです。

なぜか？
ある程度一定の間取りになっていると再現性が高いからです。

200種類あるAWSのサービスを1つ1つ勉強したところで、結局どのタイミングでどう使えばいいかがわからないと、意味がありません。
そのためAWSを学んでいく場合にはアーキテクチャの勉強こそが全てであり、アーキテクチャの観点をもつことができたら、AWSを使ってシステム設計していくことは容易になります。

過去のITシステム

極論、アーキテクチャなんてなくても、1台のスーパーサーバーを作って、全てのアプリケーションをそこで動かし、インターネットに繋げてしまえばなんでもできる環境を作ることができる！！

当然黎明期のITシステムでは、非アーキテクチャよって運用されていました。

しかし、それによって様々な問題が出てきました。

非アーキテクチャの問題点

非アーキテクチャにすると以下のような問題が出てきます。

サーバダウンによる404エラー

冗長化されていない単一のサーバがすべてのリクエストを処理するため、負荷がかかりサーバがダウンしやすくなります。
→ ユーザのリクエストに対して応答できず、ユーザーには「404 Not Found」エラーが表示され、サービス利用不可となります。

サイバー攻撃による情報漏洩

ファイアウォールや暗号化が設計されていないシステムは、外部からの攻撃に対して無防備です。
悪意のある第三者がシステムに侵入し、顧客情報や機密データが流出するリスクが高まります。

社内情報が全世界に公開

適切なアクセス制御が設計されていないシステムでは、本来社内限定であるべき機密情報が外部からアクセス可能な状態になります。
ファイアウォールやVPNの欠如、認証機能の不備により、顧客データや社内文書が全世界に公開されるリスクがあります。

上記以外にも、集中アクセスによる性能劣化、サーバーが壊れたときの全データ消失、
リリース時の不具合などが挙げられます。

非アーキテクチャの解決

非アーキテクチャの問題を解決するために、基本情報に出てくるようなアプローチでIT技術は成長してきました。

・ネットワーク
　　冗長化、疎結合化、トラフィック制御　など
・セキュリティ
　　暗号化、脆弱性スキャンなどのセキュリティ自動化　など
・ストレージ
　　用途別ストレージ選定、ライフサイクル管理　など
・データベース
　　スケール戦略、キャッシュ導入、データ分割　など
・アプリケーション
　　CI/CD　など

などなど・・・
これらすべてを抑えて、毎回設計するのは至難の業です。
なので、アーキテクチャという1つ上の視座を学ぶことで、自然と上記の問題を解決していきます。

基本的なアーキテクチャ

システムを構築するにあたり基本的な構成となるのが、WEB三層構造(アーキテクチャ)です。
WEBシステムの処理内容によって以下の3つの層から構成されます。

WEB三層アーキテクチャの特徴とメリット

特徴	メリット
保守性の高さ	各層（プレゼンテーション層、アプリケーション層、データ層）の責務が明確に分離されているため、変更や修正が必要な箇所を特定しやすく、他の層への影響を最小限に抑えられます。長期的なメンテナンスコストの削減につながります。
再利用性と開発効率	各層が独立しているため、一度開発したコンポーネントを他のプロジェクトでも再利用できます。また、チームごとに異なる層を並行して開発できるため、開発期間の短縮と効率化が実現できます。
スケーラビリティの向上	各層を個別にスケールアップ・スケールアウトできるため、システムの負荷に応じた柔軟な対応が可能です。例えば、アクセス増加時にはプレゼンテーション層のみを増強するなど、効率的なリソース配分ができます。
セキュリティ対策のしやすさ	各層が独立しているため、単体テストや結合テストが容易になります。モックやスタブを使用して層ごとにテストでき、バグの特定と修正も効率的に行えます。
層ごとの独立性	各層は明確なインターフェースで接続されているため、他の層に影響を与えずに内部実装を変更できます。これにより、段階的な改善やリファクタリングが容易になります。
柔軟な技術選択	各層に対して個別にセキュリティ対策を実施できます。プレゼンテーション層でのXSS対策、アプリケーション層での認証・認可、データ層でのアクセス制御など、層ごとに適切な防御策を講じることが可能です。

AWSにおける構成図例

以下はWEB三層アーキテクチャをAWSで実現した場合のシンプルな構成図例です。
並列処理や負荷分散を考慮することで、処理量の増加にも柔軟に対応できるシステムとなります。
縦に層を表現したので並列がずれています、すいません。。

アウトバウンドについて

先ほどまでの構成ではインバウンド（内向きの通信）についてのみ表していました。
アウトバウンド（外向きの通信）も反映させた構成図の例が以下になります。

なぜアウトバウンドが必要なのか

アウトバウンド通信の許可をする理由として、以下のような点が挙げられます。

・OS・ミドルウェア・ライブラリの更新
　　EC2やコンテナでは、以下が外部通信なしでは成立しません。
　　　　・OSアップデート（yum / apt）
　　　　・セキュリティパッチ適用
　　　　・言語ランタイムやライブラリ更新

・外部サービス連携ができない
　　以下のような外部API連携を使う前提のシステムでは必要です。
　　　　・認証（OAuth / IdP）
　　　　・メール送信（SES 以外の外部SMTP）
　　　　・決済サービス
　　　　・SaaS（Slack, Teams, Datadog 等）

アウトバウンドを持つメリット

アウトバウンド通信の許可をするメリットとして、以下のような点が挙げられます。

・運用性・保守性が向上
　　以下のように「止めない・人が触らない運用」ができます。
　　　　・自動アップデート
　　　　・監視、ログの外部送信
　　　　・SSMによるノーSSH管理

・出口を管理・制限することができる
　　アウトバウンドを認識した設計により以下が可能となります。
　　　　・プロキシを経由することによる通信先のホワイトリスト化
　　　　・フロー監視（VPC Flow Logs）

おわりに

今回の学びを通して、アーキテクチャはユーザがより便利で安全に使うために必要であることがわかりました。
システムのアーキテクチャを見たときは、なぜこのようなアーキテクチャになっているのか考えてみると全体の理解が深まると思います。

最後までお読みいただきありがとうございました！