こんにちは。プロダクト開発グループの川口です。自社サービスである FANSHIP のインフラ・運用業務を主に担当しています。
少し前になりますが、今年の3月にAWS 認定 SysOps アドミニストレーター – アソシエイト (以下 SOAA)を取得しました。その受験にあたって、普段の業務で学習・経験した知識が役立ち、公式サンプル問題と模擬試験の受験・復習のみで合格することができました。今回は FANSHIP の技術スタック紹介を兼ねて、そのサンプル問題の解説をさせていただきたいと思います。
サンプル問題はSOAAのページ上で一般公開されています。それでは早速問題を見てきましょう。
1) 企業は単一のサーバーから Application Load Balancer (ALB) の背後にある複数の Amazon EC2 インスタンス にレガシーの ウェブアプリケーションを移行しています。移行後、ユーザーがセッションの頻繁な切断、また 再ログインを求められることを報告しています。
ユーザーから報告された問題を解決するために次のうちどの措置を講じる必要がありますか?
出典: AWS 認定 SysOps アドミニストレーター – アソシエイト AWS Certified SysOps Administrator – Associate (SOA-C01) 試験問題サンプル
レガシーアプリケーション
という単語からステートフルなアプリケーションを想像できるかどうかが鍵になる問題です。ここでいうステートフルとは、サーバ側のセッション情報をアプリケーションが稼働しているサーバ内で保持している状態を指します。その様なアプリケーションが複数台のサーバで稼働している場合、リクエスト毎にロードバランサーによってサーバを切り替えられてしまうとセッションを維持することができなくなってしまいます。
FANSHIP では主に配信登録などを行う管理画面でこのセッションを使用しています。開発当初からAWSでの稼働を前提としているため、問題文の様なステートフルな設計には流石になっておらず、各サーバで共有しているデータベースにセッション情報を格納しています。ですのでロードバランサーによってどのサーバにリクエストが振り分けられても一貫してセッションが維持できるようになっています。
2) 運用チームは、毎週 AWS Personal Health ダッシュボードで、次の AWS ハードウェアメンテナンスイベントを チェックしています。最近、一人のスタッフが休暇中であったためチームはメンテナンスの予定を見落とし、そ の結果サービスが停止しました。チームはダッシュボードの確認を一人のスタッフに頼るのではなく、全員が次 のメンテナンスを周知できるような簡単な方法を求めています。
これに対処する方法は次のうちどれですか?
出典: AWS 認定 SysOps アドミニストレーター – アソシエイト AWS Certified SysOps Administrator – Associate (SOA-C01) 試験問題サンプル
CloudWatch Events (以下 CW Events)
と SNS
の一般的な機能・用途について知識があれば回答可能な問題です。CW Events は様々なAWSサービスのイベントをトリガーとして、SNS や Lambda などこれまた様々なAWSサービスの機能を自動実行させることができます。SNS も様々な用途で活用することができるサービスですが、運用面ではシステム監視としてアラートなどのイベントをSNSでパブリッシュして、Eメールや Slack などに一斉送信するパターンが一般的です。
FANSHIP でも CW Events を様々な用途で利用しています。最近ではレガシーなバッチサーバを ECS Fargate に移行した際にタスクのスケジューリングを設定しましたが、裏側は CW Events のルールが設定されています。監視では Datadog に役割を集約させているため SNS をあまり使っていないのですが、デッドレターキューサービス (以下DLQ)
と呼ばれる Lambda で何らかの理由により正常に完了できなかった処理の通知先として SNS を設定していて、DLQが通知されると SNS から Datadog に連携される仕組みを構築しています。
Personal Health は正答のような仕組みを FANSHIP では構築しておらず、ハードウェアメンテナンスの様なスケジュールイベントは、全社的に複数AWSアカウントからイベントを一括収集する Lambda を構築して把握しています。ただ、これがベストプラクティスとは限らず、本問題を解くことで見直しても良いかなと思いました。
3) VPC で稼働されているアプリケーションは異なるアカウントによって所有され、かつ別のリージョンの VPC で 稼働されているインスタンスにアクセスする必要があります。コンプライアンスの観点から、トラフィックはパ ブリックインターネットを通過してはなりません。
これらの要件を満たすために、管理者はネットワークルーティングをどのように構成すべきでしょうか?
日本語訳が少し分かりづらいですが、アカウント・リージョン・VPC跨ぎの通信をインターネットを経由せず実現する方法を問われています。ルートテーブル
はサブネット内のネットワーク経路のルールを設定するコンポーネントで、主に後述の NAT ゲートウェイ
や VPC ピアリング
などとサブネットを紐付ける設定に使われます。NAT ゲートウェイ
は主にプライベートサブネットと呼ばれる、セキュリティ上の観点でインターネット側から直接接続を確立できないようにしたいサーバを配置するネットワークを構築するために用いられます。VPC ピアリング
はVPC内のシステムが別のVPCにあるシステムにインターネットを経由せずに接続を行いたい場合に用いられます。それ以外にも、Direct Connect
に関する単語もネットワーク関連の問題に混ぜ込まれる傾向があるので概要を押さえておく必要があります。
FANSHIP ではコンポーネントという単位でシステムを機能毎にある程度分割されていて、コンポーネントが構築された時期によってVPCの構成も多少差異がありますが、基本は一般的なパブリック・プライベートサブネットでMultiAZの構成になっています。VPC周りの知識が必要となるシーンとしては、ネットワークの直接的な作業以外にも、AWS利用料金の削減を計画する際に必要となります。特にNAT ゲートウェイは代表的なコスト削減対象で、不必要なトラフィックが流れていないか各ネットワークコンポーネントの設定状態を把握する必要があります。VPC ピアリングはFANSHIPでは必要となるシーンがあまりなくほぼ使われていません。Direct Connect も自社サービスで使うことはあまり無い印象で、私も全く触ったことがないので少し学習が難しかったです。
3問目時点で思いのほか記事が長くなってしまったので、このあたりにさせていただきますが、サンプル問題はいかがでしたでしょうか。日本語情報は同難易度の ソリューションアーキテクト アソシエイトが圧倒的に多く、SOAAは影に隠れがちですが、私としてはSOAAの方が楽しく学習・取得することができました。
今回は自社サービスの FANSHIP を例に用いた紹介でしたが、クライアントワークではさらに様々なAWSサービスを活用してシステムを構築しています。SOAA で出題されるような内容をさらに業務を通して学ばれたい方や、活用できる環境を探されている方はぜひアイリッジの採用ページをご覧ください。