アプリエンジニアの視点からインフラを分類したかった（AIに分類してもらった）

## 前書きの前書き
最初はAIに添削だけしてもらうつもりでしたが、AIが非常に優れた記事を書いてくれたため、最終的にはほとんどAIに執筆してもらいました。

## 前書き
アプリエンジニアは普段アプリの開発に集中するため、インフラについて深く考える機会は少ないかもしれません。しかし、設計時にリソースの選定を行ったりパフォーマンスやスケーラビリティを考慮したりする場面でインフラの知識が必要になります。
私自身もこれまで開発に専念するあまりインフラについて深く理解する機会が少なかったため、アプリエンジニアの視点からインフラを改めて整理してみることにしました。

## インフラのカテゴリ
### コンピュート
アプリエンジニアが開発したアプリケーションは最終的にどこかのサーバに配置され、サーバのプロセスが実行します。このアプリケーションの実行に関するインフラリソースのカテゴリがコンピュートです。

昔はコンピュートとして物理サーバをそのまま使用しており、コンピュートの確保には物理サーバのCPUやメモリの確保を行う必要がありました。
ハイパーバイザー型・ソフトウェア型仮想環境が使用されるようになると、環境の排他性を確保しつつ物理サーバのCPUやメモリを環境毎に割り当てて利用できるようになりました。さらにコンテナ型仮想環境になると、ハイパーバイザー型・ソフトウェア型よりオーバーヘッドがかなり小さくなり、CPUやメモリを効率的に扱えるようになりました。クラウド上ではありますが、サーバーレスコンピュートになるとOSやミドルウェアの設定から解放され、CPUやメモリは必要に応じて(インスタンス数を増やす形で)確保されるようになりました。

|コンピュート|垂直スケーリング|水平スケーリング|クラウドサービス例|
|--|--|--|--|
|物理サーバ|物理サーバのCPU・Memoryを増強<br>事前に必要量の推測が難しく、無駄が多い|不可||
|ハイパーバイザー型<br>ソフトウェア型<br>仮想環境|VMのCPU・Memoryを増強<br>物理サーバ程ではないが無駄が多い|VMを増やす|Amazon EC2<br>Google Compute Engine<br>Azure VMs|
|コンテナ型仮想環境|コンテナのCPU・Memoryを増強<br>動的に確保しやすい|インスタンス数を増やす|Amazon ECS<br>Google Cloud Run<br>Azure Container Apps|
|サーバーレスコンピュート|自動(クラウドが管理)|自動(クラウドが管理)|AWS Lambda<br>Google Cloud Functions<BR>Azure Functions|

### ストレージ
ストレージはアプリケーションがデータを保存するためのインフラリソースであり、従来はCPU・メモリと同様に必要な容量を事前に見積もって確保する必要がありました。

昔は物理サーバに内蔵されたディスクやネットワークストレージを用意してストレージを確保していました。しかし、今現在はクラウドでは様々なストレージサービスが提供されており、事前に大容量確保しておくことも、動的に使う分だけ確保することも可能になっています。

|ストレージ|垂直スケーリング|水平スケーリング|クラウドサービス例|
|--|--|--|--|
|ブロックストレージ|ディスク容量を増加|不可|AWS EBS<br>Google Persistent Disks<br>Azure Managed Disks|
|ファイルストレージ|ノードの容量の増加|ノードを追加|AWS EFS<br>Google Filestore<br>Azure Files|
|オブジェクトストレージ|自動(クラウドが管理)|自動(クラウドが管理)|AWS S3<br>Google Cloud Storage<br>Azure Blob Storage|

### データベース

アプリケーションは多くの場合、データを永続化するためにデータベースを利用します。
昔はデータベースもコンピュート・ストレージと同様に物理的なサーバー上に配置されておりリソースの確保について同様の問題を抱えていました。しかしクラウドにおいてはそれらの問題を解決したデータベースが多数提供されています。

|データベース|垂直スケーリング|水平スケーリング|クラウドサービス例|
|--|--|--|--|
|RDB|CPU・Memory・ディスクの増強|リードレプリカの追加<br>シャーディング|Amazon RDS<br>Google Cloud SQL<br>Azure SQL Database|
|NoSQL|自動(クラウドが管理)|自動(クラウドが管理)|Amazon DynamoDB<br>Google Firestore<br>Azure CosmosDB|

### ネットワーク

アプリケーションはコンピュートやストレージ、データベース間の通信を介してユーザーにサービスを提供します。この通信のためのインフラリソースがネットワークです。

昔はネットワークを構築するために、物理的なルータやスイッチ、ロードバランサーといった機器を導入し、それらをケーブルで接続する必要がありました。クラウド環境ではこれらのネットワーク機能が仮想化・抽象化されており、物理的な機器を意識せずに動的にネットワークリソースを確保・変更できるようになりました。

|ネットワーク|クラウドサービス例|
|--|--|
|仮想ネットワーク(VPC)|Amazon VPC<br>Google Cloud VPC<br>Azure Virtual Network|
|仮想プライベートネットワーク(VPN)|AWS VPN<br>Google Cloud VPN<br>Azure VPN Gateway|
|ロードバランサー(LB)|AWS ELB<br>Google Cloud Load Balancing<br>Azure Load Balancer|
|名前解決(DNS)|Amazon Route 53<br>Google Cloud DNS<br>Azure DNS|
|コンテンツ配信ネットワーク(CDN)|Amazon CloudFront<br>Google Cloud CDN<br>Azure CDN|

### 認証・ログ

アプリケーションを安全かつ安定して運用するためには、「認証」と「ログ」の管理が重要になります。認証によって安全にリソースへのアクセスを制御し、ログによってシステムやアプリケーションの動作状況を可視化できます。これらを適切に扱うことで、システムのセキュリティや運用性が向上します。

認証は、昔は独自の認証システムを各アプリケーションで構築する必要がありましたが、現在はクラウドサービスを利用して簡単かつ安全に管理できるようになりました。
ログは、昔は各物理サーバで個別に管理する必要がありましたが、現在はクラウドでリアルタイムかつ集中管理が可能になりました。

|認証・ログ|クラウドサービス例|
|--|--|
|アイデンティティ管理(IAM)|AWS IAM<br>Google Cloud IAM<br>Azure AD|
|認証基盤(IDaaS)|Amazon Cognito<br>Firebase Authentication<br>Azure AD B2C|
|シークレット管理|AWS Secrets Manager<br>Google Secret Manager<br>Azure Key Vault|
|集中ログ管理|Amazon CloudWatch Logs<br>Google Cloud Logging<br>Azure Monitor Logs|

### セキュリティ・監視

アプリケーションを安定的かつ安全に提供するためには、「セキュリティ」と「監視」の仕組みが欠かせません。セキュリティでは不正なアクセスや攻撃からシステムを保護し、監視ではシステムの状態を常時把握して障害発生時に迅速な対応を可能にします。これらを適切に管理することで、システムの安全性と信頼性を高めることができます。

|セキュリティ・監視|クラウドサービス例|
|--|--|
|ファイアウォール(WAF)|AWS WAF<br>Google Cloud Armor<br>Azure WAF|
|DDoS対策|AWS Shield<br>Google Cloud Armor<br>Azure DDoS Protection|
|セキュリティ脆弱性診断|Amazon Inspector<br>Google Cloud Security Command Center<br>Azure Security Center|
|インフラ監視|Amazon CloudWatch<br>Google Cloud Monitoring<br>Azure Monitor|
|アプリケーションパフォーマンス監視|Amazon CloudWatch Application Insights<br>Google Cloud Monitoring<br>Azure Application Insights|
|分散トレーシング|AWS X-Ray<br>Google Cloud Trace<br>Azure Application Insights|

### バックアップ・リストア・災害対策（ディザスタリカバリ：DR）

システム運用において、万が一の障害や災害から迅速に復旧するためには、「バックアップ・リストア」および「災害対策（DR）」が非常に重要です。これらの仕組みが整備されていることで、データ損失のリスクを軽減し、障害発生時にも迅速にサービスを再開できます。

従来はバックアップの取得・管理や災害対策の仕組みを独自に構築・運用する必要がありましたが、現在はクラウドサービスを利用することで、簡単かつ柔軟に導入できます。

|バックアップ・リストア・災害対策|クラウドサービス例|
|--|--|
|ブロック・ファイルストレージのバックアップ|AWS Backup<br>Google Cloud Persistent Disk Snapshot<br>Azure Backup|
|オブジェクトストレージのバックアップ|AWS S3 Versioning<br>Google Cloud Storage Versioning<br>Azure Blob Storage Versioning|
|データベースのバックアップ|Amazon RDS Snapshot<br>Google Cloud SQL Backup<br>Azure Database Auto-Backup|
|クロスリージョンレプリケーション|AWS S3 Cross Region Replication<br>Google Cloud Storage Multi Regional Configurations<br>Azure Blob Storage Geo-Redundant Storage|
|グローバルデータベース・レプリカ|Amazon Aurora Global Database<br>Google Cloud SQL Cross-Region Replica<br>Azure SQL Database Failover Group|
|フェイルオーバー・復旧|Amazon Route 53 DNS Failover<br>Google Cloud Load Balancing Global Failover<br>Azure Traffic Manager|

### メッセージング・キュー・イベント駆動

アプリケーションの開発では処理を同期的に行うのではなく非同期的に処理することでパフォーマンスや耐障害性を高めることができます。非同期処理を実現する代表的な仕組みが「メッセージング」や「キュー」、および「イベント駆動」です。

かつてはこれらを実現するために専用のサーバを立てて運用・管理する必要がありましたが、現在ではクラウドサービスを利用することで簡単かつ柔軟に導入できます。

|メッセージング・キュー・イベント駆動|クラウドサービス例|
|--|--|
|メッセージキュー|Amazon SQS<br>Google Cloud Pub/Sub<br>Azure Service Bus Queue|
|パブリッシュ・サブスクライブ|Amazon SNS<br>Google Cloud Pub/Sub<br>Azure Service Bus Topic|
|ストリーミング処理|Amazon Kinesis<br>Google Cloud Dataflow<br>Azure Event Hubs|
|イベントルーティング|Amazon EventBridge<br>Google Cloud Eventarc<br>Azure Event Grid|

### API管理・ゲートウェイ

アプリケーションの機能を外部に公開したり複数のシステムを連携させたりするためには、適切なAPI管理・ゲートウェイが必要です。APIを安全かつ効率的に公開・管理することで、外部システムやアプリケーションと柔軟に連携しやすくなります。

従来は独自のAPIサーバを構築しセキュリティや負荷分散、トラフィック管理などを自前で行う必要がありましたが、現在はクラウドサービスによって容易に導入・運用できるようになりました。

|API管理・ゲートウェイ|クラウドサービス例|
|--|--|
|APIリクエスト管理・ルーティング・<br>認証認可・トラフィック制御・レート制限|Amazon API Gateway<br>Google Cloud API Gateway<br>Azure API Management|
|APIライフサイクル管理・バージョニング・<br>APIドキュメント管理|Amazon API Gateway<br>Google Cloud Endpoints<br>Azure API Management|
|APIモニタリング・分析|Amazon CloudWatch<br>Google Cloud Monitoring<br>Azure Monitor|

### CI/CD・デプロイメント・開発支援ツール

アプリケーション開発において開発効率を高め頻繁かつ安全にアプリケーションをリリースするために、「CI/CD・デプロイメント」や「開発支援ツール」を導入することが重要です。

従来はCI/CDのためのサーバやツールを自前で用意し運用する必要がありましたが、現在ではクラウドサービスを利用して簡単に構築・運用することが可能になっています。

|CI/CD・デプロイメント・開発支援ツール|クラウドサービス例|
|--|--|
|継続的インテグレーション(CI)|AWS CodeBuild<br>Google Cloud Build<br>Azure Pipelines|
|継続的デリバリー(CD)|AWS CodeDeploy<br>Google Cloud Deploy<br>Azure Pipelines|
|コンテナレジストリ|Amazon ECR<br>Google Artifact Registry<br>Azure Container Registry|
|Gitリポジトリ|AWS CodeCommit<br>Google Cloud Source Repositories<br>Azure Repos|

## 後書き
クラウドサービスの台頭によって、アプリケーションエンジニアにとって考えるべきITインフラの範囲は飛躍的に広がり、細分化されました。一見すると複雑になったようにも感じられますが、カテゴリごとに丁寧に整理しきちんと把握していけば、スケーラビリティ・セキュリティ・可用性を備えた最適なインフラを構築することが可能です。

良いインフラの構築は、アプリケーションを適切に、そして効率よく動作させるための土台となります。これを実現するためには、クラウドサービスが提供する各種リソースや機能を理解し、それらを適切に組み合わせて活用することが重要です。

ぜひこの機会に、開発するアプリケーションがどのようなインフラ上で動いているのかを意識し、インフラに対する理解を深めてみてください。その一歩が、アプリケーションの信頼性向上やチーム全体の開発力向上にも繋がるはずです。

## 後書きの後書き
もう記事は人間が書く時代じゃないと思いました。