📚

How to use technology AWS and Container

6 min read 3

前提条件

本記事では2021.09.01の情報をもとに執筆しております。
公式の情報と差異が発生した場合は公式の情報を優先とします。
随時更新をいたします。
今回ではContainerとAWSを使ってWebAPIを公開してみる場合のユースケースを検討します。

対象

AWSでContainerを活用しようとしているdeveloper
API公開を行う前提で記載してますが結構幅広いユースケースに対応できるかなと思っています。

前提知識

AWS基礎知識

AWSにおけるContainer WEBAPI公開において考えるべき事項

APIによっては他にも考えるべき事項はあるかと存じますが、これだけは外せないだろうというところを厳選させていただきました。

  1. API公開・アクセス制御
  2. 負荷分散
  3. アプリケーション実行基盤
  4. アプリケーション実行環境
  5. イメージ管理
  6. データベース
  7. ストレージ
  8. 監視
  9. ルーティング・ドメイン制御

概念解説と使用想定サービス

1. API公開・アクセス制御

API Gatewayの公開はAWSの場合は基本的にAmazon API Gatewayを使用するほうがメリットが大きいです。
以下理由を記載しますが、AWSが簡単にデプロイできるように用意してくれているのなら使用したほうが車輪の再開発を防げると思います。

  • 勉強用で作るのでは話が別です。

理由

  1. 低コストで利用可能
  2. バージョン管理
  3. モニタリングの容易性
  4. 柔軟なセキリュティ

特にアクセス制限や認証についてはAWS Cognitoやリソースポリシーを使用して管理することができる。またAWS WAFによる脆弱性対策も対応することが可能です。

AWS WAF を使用して API を保護する

負荷分散

AWSでの負荷分散はELBが担います。ELBには3種類あります。

  1. Application Load Balancer(ALB)
  2. Network Load Balancer(NLB)
  3. Classic Load Balancer(CLB)ze

それぞれに、どのレベルのレイヤで動作するかが変わります。
ELBについて理解することはAWSのアーキテクチャーを組むうえでも重要ですので、以下の公式ドキュメントを参照してください。
Elastic Load Balancing

アプリケーション実行基盤

コンテナを動かすサービスは何か?という観点で整理するとAWSでは以下のサービスが挙げられます。

  1. Amazon EKS
  2. Amazon ECS

他にもAmazon RedHat OpenShift Platform Servicesなどがありますがこちらは、RedHatを使用するケースの際に登場します。まず検討するのはEKS,ECSのため割愛します。
特にkubernetesという概念が出てきますので、こちらは補足すると

Kubernetesは、宣言的な構成管理と自動化を促進し、コンテナ化されたワークロードやサービスを管理するための、ポータブルで拡張性のあるオープンソースのプラットフォームです。
公式サイトより引用 : https://kubernetes.io/ja/docs/concepts/overview/what-is-kubernetes/

コンテナ化されたアプリケーションをいい感じに管理してくれるサービスだと思ってもらえれば大丈夫です。

アプリケーション実行環境

アプリケーション実行環境とは、実行基盤の上に乗せるアプリを動かすための環境のことです。今回はEC2かFargateが選択肢に上がります。
私は完全にFargate推しです。

  • EC2を選択する場合のデメリット
    EC2クラスターの管理コストがかかる
    デプロイ速度が遅い(EC2を先に起動してからという手間が入る)
    スパイクの対応品質が悪い(オートスケーリングはできるが、EC2の起動速度から対応が後手になりがち)

  • Fargateにした場合の対応
    コスト増の懸念があるもののEC2の際のデメリットをケアできるため、お金をはらってメリットを購入するイメージになります
    特にEC2を選択した場合におけるデメリットをケアしつつ開発効率を上げるとなると嬉しい限りです。

イメージ管理

Amazon ECR一択になると思います。
Docker hubも使用が検討できると思いますが、AWSが提供しているサービスなので合わせたほうが無難だと思います。

データベース

データベースはAmazon RDSを使用するケースとEC2などを使用し手組で入れる場合があると思います。基本的にはメンテナンス等も考えAmazon RDSの使用を検討するべきでしょう。
RDSの場合はAuroraかそれ以外かという選択肢もあります。要件に合わせて使用することが重要です。
Aurora推しなので、ここではAmazon Auroraをベースに説明します

Amazon Aurora ってなんやねん!

blackbeltの以下よりイメージ図を引用します。

https://www.slideshare.net/AmazonWebServicesJapan/20190828-aws-black-belt-online-seminar-amazon-aurora-with-postgresql-compatibility-168930538
Amazon RDS と Amazon Auroraの違いをアーキテクチャーの観点から見ていきたいと思います。

Amazon RDSのアーキテクチャー


Amazon RDSですが、このアーキテクチャーだとプライマリーとスタンバイの2つが用意されています。それぞれにEBSストレージが紐づいていて、これらがミラーリングしていることによって耐久性を高めています。

Amazon Auroraのアーキテクチャー


Amazon AuroraはDBクラスターを作成します。いわゆる大きな箱のようなイメージです。このなかにインスタンスとストレージが入っているのですが、RDSとちがい、インスタンスとストレージが分離しています。
ストレージがさらに1AZに2か所,それが東京リージョンだと3AZ分すべてにコピーされます。これらは同期的に通信をしているため、もし何かデータの消失が起こっても他のインスタンスが修復しあう関係になっています。
また書き込み自体も並列に行うため処理自体のパフォーマンス自体にも大きな影響は与えません。
Amazon Auroraにも独自機能があります。AWSが提供している分かなり高機能なのでアプリ要件を十分に検討したうえで、導入を検討する余地があります。

ストレージ

ストレージについてはEBS,EFS,S3を使用する選択肢があります。アプリケーションにおいて使い分けることが大事です。
通常はEBSかS3を選択するケースが多いかなと思います。
ファイルディレクトリとしては、耐久性や疎結合にするといった観点からS3などをベースに検討されたほうがいいかと思います。

監視

基本的にAWS Cloudwatchがすべてを見ていると思ってもらってOKです。ECSの場合は、標準出力にしないとログが見れないのでその点注意しましょう。
EKSは自分でログを出すようにサービスと連携したり、コンテナをデプロイする必要があります。

ルーティング・ドメイン制御

Amazon Route53の出番ですね。結構奥が深いサービスです。
基本的にELBのサービスを使って紐づけることが前提なので、自分の好きなドメインを設定するのに使うんだなといういめーじを持ってもらえれば大丈夫です。

  • AWSの場合はRoute53を使用してドメインの制御をするほうが何かと便利です。お名前.comなども使用することはできますが、ネイキッドドメインが公開できないなど制約がかかる場合がありますのでご注意ください。

AWS ECS,EKSを利用したアーキテクチャーイメージ

アーキテクチャーのサンプルです。このような図になるイメージです。
注意点として

  1. ALBはサブネット3つ分にわたって稼働できるように設計するという意味で3つ記載している
  2. NAT Gatewayは冗長化している(高いので1個にしてもいいかもしれない)
  3. ECSのところをEKSに置き換えてもらうことも可能(サブネット構成は若干変わります)
  4. EKSの場合はIstioやApp meshなどがでてきたり、ingress controllerもでてきたりするのでもう少し複雑になる

これらの点は注意してご確認ください、あくまでサンプルです。

AWS configの注意


AWS Configの設定に注意する必要があります。ECS、EKSはデプロイの回数が多く、パブリックIPやプライベートIPのIP割り当てもAWS Configはチェックします。
開発時期はとにかくテストして修正という数が多いので知らないうちにここまで料金が増えているというケースもあります。
AWS configについては公式ドキュメントを見ながら特に理解することが必要です。

料金見積もりについての考え方

AWSでこの料金を見積もるのは前提条件をもっと出さないといけませんが最低2500USDくらいから見る必要があります。

  • 詳細な見積もりの考え方は別で執筆予定

AWS WAFセキリュティ考慮事項

AWS WAFにセキリュティ対策を任せるということを検討した場合は以下のルールを検討する必要があります。
参考に表にまとめていますがすべて対応する必要があるというわけではないです。

セキュリティの虚弱性 対応方針
インジェクション系
SQLインジェクション
OSコマンドインジェクション
クロスサイトスクリプティング
ディレクトリトラバーサル
クロスサイトリクエストフォージェリ
AWS Managed rulesで次のルールセットを有効化する
Core Rule Set
SQL Database
PHP Application
ウェブの管理者ページの保護 AWS Managed rulesのAdmin Protectionルールセットを有効化
DDoS攻撃からの保護 Rate Based Rulesによる同一IPからの短時間での大量アクセス拒否
IP Blacklistに追加して特定のIPを拒否する
AWS Managed rulesの Amazon IP reputation list および Anonymous IP Listルールセットの有効化
BOTによるアクセスの対策 Rate Based Rulesによる同一IPからの短時間での大量アクセス拒否
IP Blacklistに追加して特定のIPを拒否する
AWS Managed rulesの Amazon IP reputation list および Anonymous IP Listルールセット、Known Bad Inputsルールセットの有効化

まとめ

以上containerについてまとめてみました。まだ記載途中の部分もありますが、考えるべき点はあらかたまとまっていると存じます。
ご意見等ございましたら遠慮なくご指摘ください。よろしくお願いします。

Discussion

知識の整理に非常に有益な記事でした! ありがとうございます
RDSのくだりの画像ですがauroaのほうはあっていますでしょうか? ご確認おねがいします🙏

ありがとうございます。
今気がついたんですが、これどちらもAuroraのアーキテクチャーの画像でした。
差し替えます

修正しました。
ご指摘いただきありがとうございます。

ログインするとコメントできます