2016年12月20日からスタートしたMBS（毎日放送）の有料動画配信サービス『MBS動画イズム444』にて、サーバーレス・アーキテクチャ（AWS Lambda）が全面採用されたという事例は、世界を見渡しても類をみない、大変優れた設計であると話題になりました。
でもね、重要なことは「AWS Lambdaを使って構築した」ことではないんです！
『MBS動画イズム444』は、次々と新しい動画コンテンツが増えていますし、有料会員も猛スピードで増えていると伺っています。そうなると、このサービスの安定運用こそが、もっとも重要なことなのです。
そこで、この記事では「AWS Lambda」で構成されるシステムの運用をcloudpackならこうやります！というのをご紹介いたします。
サーバーレス・アーキテクチャのシステム運用はどう考えるべきか？
『MBS動画イズム444』のシステム構成は、実に複雑です。
サーバーレス・アーキテクチャで構築されたシステムは、AWS Lambdaごとに機能が分割されるため、どうしても複雑になりがちです。
一般的に、Amazon EC2で構成されたシステムを運用する場合、監視やモニタリングツールのエージェントをEC2にインストールして、障害時に通知を受ける形になります。
しかし、サーバーレス・アーキテクチャの場合は、そう一筋縄にはいきません。
AWS LambdaやAmazon API GatewayなどのAWSプロダクトは、AWSがフルマネージメントサービスとして提供されているため、エージェントツールをインストールすることができません。
ユーザーが作成したもの（AWS Lambdaでいえば”function”）は、ユーザー自身が管理・コントロールする必要があります。
また、課題になるのは、運用を行うための環境です。
サービス環境がサーバーレス・アーキテクチャでコストダウンを図っているのに、運用環境にAmazon EC2を利用してしまうと、運用コストの方がサービス環境のコストよりも高くなってしまう可能性があります。これでは本末転倒です。
外部の監視サービスを使っても同様です。さまざまな魅力的な監視ツールがあるので手を延ばしたくなりますが、AWSの利用料金と比較するとやはり割高になってしまう傾向があります。
自称AWSプロフェッショナル集団のcloudpackとしては、答えはひとつ！
『サーバーレス・アーキテクチャの運用は
サーバーレス・アーキテクチャで行うべし！』
AWS Lambdaを『監視する』とは？
基本的には、メトリクスとログの監視、そしてURL監視を行っております。
メトリクス監視は、AWSプロダクトごとに用意されているメトリクスをAmazon CloudWatchで監視します。
ログ監視は、運用基盤側に配置するAWS Lambdaから対象となる各AWSプロダクトを監視します。
監視結果は、JSON形式でS3に吐き出し、JSONデータ内に異常があるかをAWS Lambdaで確認します。万が一、データ内に異常があれば、AWS Lambdaからキックする形で運用メンバーに通知されます。
さらに、ログ監視の延長で不正アクセス対策も盛り込んでいます。
AWS Lambdaの制限事項
AWSのドキュメントに書かれているので、ご存知の方も多いと思いますが AWS Lambdaの実行回数には、制限が設けられています。
必要に応じて上限緩和申請を行えばいいのですが、不正アクセスを試みるハッカーにAmazon API Gatewayのエンドポイントが特定されて高負荷なアクセスが行われると、アクセスされた回数分だけAWS Lambdaが実行されるため、本来、できるはずの実行回数が減ってしまうのです。
その結果、正しく必要な処理が実行されなくなり、最悪の場合でサービスダウンが発生してしまう可能性があります。
このような背景から、『MBS動画イズム444』の運用環境では、少し工夫をしています。
Amazon CloudWatch LogsにIPアドレスを保存しているため、同一IPから一定時間内に複数のアクセスを見つけた場合には、自動的にAWS WAFに当該IPアドレスを登録してアクセスを遮断する仕組みを用意して、安定した運用を実現しています。
AWS Lambda監視用GUIも開発
また、実際に運用をするcloudpackの運用メンバーの作業効率を考慮しています。
このシステムの構築と合わせて 監視モニタリング用のGUIも開発したため、他のシステムの運用と手続きを変えることなく対応できるようにしています。
AWS Lambdaベースの運用基盤の可用性を高める
十分な監視ができるようになっても、対応すべき点はまだあります。
運用基盤がダウンした場合はどうなるのでしょう？ 監視ができなくなるだけでなく、不正アクセスも防げなくなります。
cloudpackとして 運用基盤の可用性を高めるにはどうすればいいのか？
導いた答えは、複数リージョンに運用基盤を用意して監視をする、でした。『MBS動画イズム444』では、3リージョンを活用して監視を行っています。
複数のリージョンからも、「サービスの監視」と「運用基盤の監視プログラム」を監視すれば、万が一メインの運用基盤で障害が起こっても、他のリージョンの運用基盤から監視を継続できるようになります。
これが、可用性を考慮しながら、運用基盤をサーバーレス・アーキテクチャで構築したcloudpackの解です。
AWSの利用料金は増えないのか？
EC2のように長時間稼働させることがありませんので、むしろ利用料金が下がります。
具体的には、下記のAWS利用分のコストがかかります。
- AWS Lambdaの実行回数／時間
- Amazon CloudWatchのAPIリクエスト
- Amazon API Gatewayへのリクエスト（URL監視時のみ）
- Amazon CloudFrontへのリクエスト（URL監視時のみ）
また、監視モニタリング用のGUIは、S3に保管したJSONデータを取得して表示するため、ブラウザでモニタリング画面を開いていないときはコストがかかりません。
これらの結果、EC2で構築する運用基盤と比較をしても、大幅にコストを抑えることができます。
サーバーレスの運用は、やっぱりサーバーレスで！
他にもよい運用方法はあるかもしれませんが、cloudpackはこう運用しているという事例として紹介しました。
AWS Lambdaによるシステム構築も運用も、cloudpackにお任せください！
最後まで読んでくださり、ありがとうございました。
