こんにちは、9月頃に開花させたベランダ菜園のバジルが12月になっても枯れないので種が収穫できません。
OTTサービス事業部の宮田です。
私の所属するチームは主にフロント向けのアプリ(web、iOS、Android、etc...)の開発を行っているフロントエンドエンジニアの集団です。
ですが、この種のアプリはフロントエンドだけでは完結しません。
バックエンドAPIが必要だし、WEBも環境によってはサーバインフラを必要とします。
バックエンド担当、インフラ担当との円滑なコミュニケーションやトラブルシューティングを行うためには、フロントエンドエンジニアもバックエンドやインフラについて知っておいたほうが良いと考えています。
そこで今回は当部署でよく利用しているAWSサービスや構成例を紹介したいと思います。
サービス紹介
コンピューティング
EC2 (Elastic Compute Cloud)
AWSクラウド上で稼働する仮想のサーバマシン(インスタンス)を提供するサービスで、物理ハードウェアリソースのインフラをAWS側が管理し、その上に構築した仮想サーバを利用する仕組みになっています。
OS/CPU/メモリ/ストレージ/ネットワーク等サイジングオプションも自由に選べてすぐに構築できます。
アプリケーションがインストールされていないため、環境構築は各自で行う必要があります。
ECS (Elastic Container Service)
Dockerコンテナに対応したコンテナの管理・実行をするサービスです。コンテナを実行するコンピューティングにはEC2かFargateを利用することができます。
Fargateを使う場合はコンテナを実行するインスタンスの管理をAWS側で自動的に行うようになります。
EC2の場合はインスタンスのスケーリングや状態管理など自前で行う必要がありますが、FargateとEC2を同じぐらいのインスタンス構成にした場合にEC2のほうが20%程度料金が低い傾向があります。
管理コストと稼働コストを比べてEC2かFargateを選ぶと良いでしょう。
Lambda
EC2やECSと違いサーバレスなコンピューティングで、ランタイムを選んでソースコードをアップロード or 管理画面に備え付けのエディタでコーディングすることですぐに利用可能です。
イベント駆動型のため、S3やCloudWatch EventsなどのAWSサービスと連携して処理を行うような使い方が多いです。
並列実行させることも可能です。例えばCloudWatch Eventsで指定時間にLambdaを一つ実行します。このLambdaではDBから処理対象の一覧をピックアップして対象の情報を1件ずつSQSにキューイングさせるところまで処理します。SQSもLambdaとの連携が可能なので、キューが入ったタイミングでキュー1件分にたいして処理を行う別Lambdaをキューの数に合わせて並列で実行させることで、多数のデータを短時間に処理するようなバッチを組めます。
データベース
RDS (Relational Database Service)
名前の通りリレーショナルデータベースを提供するサービスで、Amazon Aurora、MySQL、MariaDB、PostgreSQL、Oracle、Microsoft SQL Serverの6種類のエンジンを使用でき、パッチ適用やバックアップなどの運用作業も簡単に管理できます。
Amazon Auroraは、Amazon公式ではMySQL or PostgreSQLと完全な互換性があると謳われているエンジンで、元となったそれぞれのエンジンと比べてパフォーマンスやスケーリングの柔軟性、可用性を向上させたものになります。
EC2のように利用したいインスタンスを選ぶタイプで、一つのRDSクラスタに複数のインスタンスを入れる形でスケールさせます。
ElastiCache
RedisかMemcachedをマネージドな環境で提供するサービスです。
Redis、Memcachedは共にメモリ上でデータ管理をするkey-valueでNoSQLなDBです。
EC2のように利用したいインスタンスを選ぶタイプで、一つのElastiCacheクラスタに複数のノードを入れる形でスケールさせます。
DynamoDB
key-valueまたはドキュメント指向をサポートしたNoSQLでサーバレスなDBです。
スケーリング設定は2種類あり、一つは1秒間で行う読み/書きの想定回数をキャパシティユニットとして指定するプロビジョニングモード、もう一つはリクエスト頻度に合わせてスケールするオンデマンドモードです。
プロビジョニングモードはある程度利用量がわかっていて設定する分、コストの予測も簡単で、性能あたりの単価が安く設定されていますが、急な大量アクセスに対応できません。オンデマンドモードでは急な大量アクセスでも自動的にスケーリングするので捌けますが、料金がリクエスト回数に依存するため見通しが難しいです。
ストレージ
S3 (Simple Storage Service)
データを保存・管理するオブジェクトストレージサービスです。
保存したデータのアクセス頻度、コストなどの要件に合わせて選択できるストレージクラスが用意されており、頻繁にアクセスが有るものは通常のクラスを選びますが、例えば年に1〜2回程度しかアクセスしないようなファイルは、Glacierと呼ばれる低コストな代わりにデータの取り出しに時間がかかるクラスを使うこともできます。
ファイルの保存のほか、ファイルをHTTP(S)経由で配信することも可能であり、一般的にはCloudFront経由で配信することが多いです。
ファイルパスなどを利用したライフサイクルを設定することが出来て、たとえば最初はスタンダードクラスのストレージに設置し、特定のファイルパスで始まるファイルの場合は保存して60日経ったらGlacierに移動、さらに90日経ったら削除するといった設定をして、使わないデータの管理を自動化できます。
配信・負荷分散
CloudFront
動画、画像などの静的なコンテンツを大規模に配信するためのネットワークを提供するサービスです。世界各地に展開されているサーバにデータをキャッシュさせることで、クライアントから見た応答速度を短縮できる上に、配信元の負荷を軽減することができます。こういったネットワークをCDN(Content Delivery Network)と呼びます。
コンテンツの配信元(オリジン)として、S3バケットやALB、外部のサーバなどが選べます。
CloudFrontへのリクエストのURLパスとオリジンへのルーティングをビヘイビアという名前でグルーピングして、ビヘイビア単位でキャッシュする時間やルール、オリジンへ渡すヘッダーやcookieなどのフィルタリングを設定できます。
ALB (Application Load Balancer)
ロードバランサー(Load Balancer: LB)とは与えられた通信を複数のサーバに分散させて1台あたりのサーバ負荷の軽減や、障害などで通信できなくなったサーバを切り離すことでサービスを維持するような機能を指します。
ALBは正確にはELB(Elastic Load Balancer)の中の機能の一つで、OSI参照モデルでいうレイヤー7(アプリケーション層)向けとしてHTTP/HTTPSに対応しており、URLのパスベースでのルーティングや重み付けによる分散制御が行なえます。
WAF
ウェブリクエストを許可、拒否、または監視(カウント)するルールを設定し、ウェブアプリケーションを攻撃から保護するWebアプリケーションファイアウォール(Web Application Firewall)です。設定できる条件には、リクエスト元IPアドレスやHTTPヘッダー、HTTPリクエストボディやURLパス等があります。
構成例
当部署で実際に利用している構成例を紹介します。
構成例1：WEBアプリ
当部署ではNode.jsでReactとExpressを組み合わせたサーバサイドレンダリング(SSR)/クライアントサイドレンダリング(CSR)/APIを展開していまして、サーバサイドのNode.jsを稼働させるためにECSを、セッション管理用にElastiCache Redisを利用しています。
また、静的ファイルはS3に設置してあり、CloudFrontで特定のパスの場合だけS3へ、それ以外はALBを使うような設定をしています。
構成例2：サービス用API
APIのメイン部分はRuby on Rails製でEC2にて稼働、サブAPIとしてNode.js製とGolang製のAPIをECSで稼働させています。
データベースはAurora PostgreSQLを、全文検索用にElasticsearchをEC2で用意していますが、負荷対策としてメタ情報やユーザ情報等をElastiCache RedisとS3上に保存し、単純なリソース取得の場合は優先的にRedis、S3を利用するようにしています。
CloudFrontから直接参照しているS3にはエラー用の固定HTMLが設置してあり、APIで提供しているパスをビヘイビアに定義することで、ビヘイビアの条件に引っかからなかった場合はアプリ側で処理せずに404エラーを表示させています。
まとめ
今回は当部署でよく利用しているAWSのサービス紹介や構成例についてご紹介しました。
初回ということで入門編のような位置づけとしておりますので、次回はもっと踏み込んだ内容をご紹介できればと思います。
