AWSアーキテクチャ道場「Infrastructure as Code（IaC)でSNS風Webアプリをデプロイする」──AWS Tech talk Night#4

イベント公開日: 2023/02/06

ブックマーク

AWSのソリューションアーキテクトがアーキテクチャの極意を伝授する「AWS Tech talk Night」第4弾。今回はSNS風アプリ開発をテーマに、AWSソリューションアーキテクトによるアーキテクティングをロールプレイで疑似体験する試みと、Infrastructure as Code（IaC）の基本解説とライブコーディングが行われた。その様子をレポートする。

#AWS, #Node.js, #TypeScript, #React

AWS

アーカイブ動画

アーキテクティングは「WHY」を明らかにする作業

今回のイベントではソリューションアーキテクトの高野賢司氏、吉川幸弘氏をはじめ、プロトタイピングエンジニアの友岡雅志氏、工藤朋哉氏が登壇。多様なバックグラウンドをもつAWSのソリューションアーキテクトのなかでも、開発者の体験や生産性を向上させるサービスや、実際にアプリ開発を行うことに強みを持つ4名だ。

最初に登壇した高野氏は、「アーキテクティングとは、お客様目線で情報を整理し、システムの構造と特性を設計するプロセスだ」と語る。

例えばアーキテクトが、「自動車のデータを収集して、故障の原因を分析したい」と相談を受け、どんなシステムを作ればよいかを考える際は、以下のようにさまざまな疑問が出てくるはずだ。

「自動車のデータ」とはどんなデータなのか
どうやってデータを集めればよいのか
データが集まって分析できるとお客様のビジネスはどのように変わるか
車の所有者であるエンドユーザーの体験はどのように変わるか
開発体制や運用プロセスはどのようになるか

お客様との対話によって、アーキテクトはお客様が無意識に要求しているものや、見えないエンドユーザーの思いまで想像しながら複雑な要求を体系化し、なぜこのシステムが必要なのか背景と目的をまとめる。そしてこれを実現させるためのシステム構造や備えるべき特性を検討をしていくわけだが、このとき採用しなかった代替案やトレードオフについてまとめておくことも欠かせない。構造に現れてこない部分に関しても設計指針という形で残していく。この一連のプロセスがアーキテクティングだ。基本的にアーキテクチャには唯一の正解はないため、重要となるのが「なぜこのシステムが必要で、どのような議論を経てこの判断をしたのか」という「WHY」だ。

アーキテクティングを主な業務とするアーキテクトには、幅広い技術力、様々な経験、最新の技術トレンドといった技術関連のスキルだけではなく、事業ドメインに関する知識やコミュニケーション能力などが求められる。アーキテクトは、複雑なものを単純化するスペシャリストだ。

アーキテクティングのロールプレイ

ロールプレイの設定はこうだ。高野氏がソリューションアーキテクト、工藤氏が相談に来た顧客、あるスタートアップ企業に勤めるアプリケーションエンジニアという役回りで、「boyaki」というSNSサービスの実現に向けてアーキテクティングを行っていく。

まずはヒアリング部分から見ていこう。

■ヒアリング

工藤：こんにちは、アプリケーションエンジニアの工藤です。今日は、AWSのソリューションアーキテクトさんに新しいサービスのアーキテクチャについて相談してきました。

高野：ご相談ありがとうございます。まずは、どんなサービスをご検討中なのか詳しくお聞かせください。

工藤：ユーザーが今考えていることを気軽にぼやくことができる「boyaki」というSNSサービスです。

高野：なるほど、おもしろそうですね。これはインターネットに公開することを想定したサービスですか？

工藤：インターネット上に公開して、誰でもアカウントを取得してぼやくことができます。

高野：これから開発運用していく上で重視することは何でしょうか。例えば、「初期ユーザーを獲得するためにパフォーマンスを上げたい」「とにかくコストを抑えたい」「機能追加がしやすい形にしたい」などがあると思います。

工藤：開発チームが3人しかいないので、開発効率を一番重視したいと思っています。また、サービス開始直後、ユーザーが少ないときのコスト効率を重視したいと思っています。

高野：小さなチームですばやくサービスを作る必要があるということですね。また、サービスが収益化するまで支出を抑えたいというところかなというふうに理解しました。

では次に、最初のリリース時に最低限必要な機能（MVP：Minimum Viable Product）は何でしょうか。　

工藤：とりあえず欲しいのは、メッセージを投稿する機能、投稿されたぼやきを時系列に表示する機能です。将来的には、過去の投稿の検索や友達のアカウントをフォローする機能も欲しいと思っています。AWSでそういった機能を実現するためには何が必要でしょうか。

高野：まずは、メッセージの投稿機能が必要ということですね。将来的にご検討されている機能については、全文検索やフォロー機能になると思います。データベースが関連するものですので、アーキテクチャ図を書きながらディスカッションしていければと思います。

最後に、アプリを構成する技術スタックのご希望や、アーキテクチャに関するリクエストがあれば教えていただけますか。

工藤：我々はNuxt.jsが得意なので、Nuxt.jsのシングルページアプリケーション（SPA）で作りたいと思っています。開発チームはアプリエンジニアのみでインフラに詳しい人がいないため、インフラの運用を意識しないアーキテクチャがいいと思っています。

高野：要件は大体把握できました。では、アーキテクチャを一緒に考えていきましょう。

■アーキテクチャのディスカッション

高野：まずはシンプルなアーキテクチャから始めていきたいと思います。ユーザー目線から考えてみましょう。

シングルページアプリケーションは、ユーザーがURLにアクセスすると、Amazon CloudFrontというCDNサービスからアプリが配信されます。今回はNuxt.jsを使われるとのことなので、Amazon S3バケットにコードを格納しておきます。

次に、ぼやきの投稿や取得には認証も必要になりますので、Amazon Cognitoで認証します。
アプリからぼやきを投稿したり、取得したりするにはAPIを呼び出します。APIから、ビジネスロジックを処理するコンピュートサービスを呼び出し、データベースにアクセスします。コンピュートサービスでは、サーバーサイドのコードを実行する必要があります。

工藤さん、こちらはどの言語やフレームワークを使う予定でしょうか？

工藤：最近出たNuxt.jsのバージョン3が、Lambda関数やコンテナなど、それぞれの環境に合わせたコードを出力できるので、それを使いたいと思います。

高野：では、そのコンピュートサービスに何を使うか検討していきたいと思います。インフラを意識したくないとのことなので、今回はEC2のような仮想マシンベースのものは除外してよいと思います。関数のコードだけで実行できるAWS Lambdaか、コンテナサービスになると思います。工藤さんはコンテナを使ったサービスの運用経験はありますか？

工藤：開発中はDockerなどのコンテナをよく使いますが、本番サービスをコンテナで運用した経験がないので、運用には少し不安があります。

高野：今回はAWS Lambdaで作り始めることを提案します。Lambdaであれば、コンテナイメージの管理やスケーラビリティを考える必要がありません。Lambdaは関数のコードを管理するだけです。Lambda特有の設定やパフォーマンス特性などの学習コストは必要ですが、また、Nuxt.jsならLambda用コードを出力できるので、学習コストも抑えられると思います。

工藤：後でコンテナにする際も、Nuxt.jsの機能で移行できそうです。コスト的にはどうでしょうか。

高野：ユースケースによりますが、ユーザーが少ないサービス開始当初であれば、Lambdaのほうが、AWS利用料や開発運用コストも抑えられる可能性が高いと思います。

工藤：では、コンピュートサービスはまずLambdaでやってみます。残りはデータベースの部分ですね。データベースについて、何かおすすめはありますか？ DynamoDBに興味がありますが、まだMySQLしか使ったことがありません。

高野：Amazon DynamoDBは KVS（Key-Value Store）と呼ばれるタイプのデータベースになります。シンプルなクエリしかできない代わりに、大量にアクセスされた場合も高速にレスポンスを返すことが可能です。基本的にSQL文を投げるのではなくて、APIで操作することになります。

工藤：パフォーマンスが悪いとユーザーが離れてしまうため、パフォーマンスは大事にしたいと思います。将来的には全文検索など、複雑な検索が必要になってくると思いますが、これもDynamoDBで実現できますか？

高野：DynamoDBのテーブル設計次第では、ハッシュタグ検索といった要件にも対応できると思います。ただ全文検索や複数の条件を組み合わせた複雑な検索に関しては、別のデータベースサービスを組み合わせることをおすすめします。

例えば、全文検索にはAmazon OpenSearch Serviceが使えます。友達をフォローする機能には「友達の友達を探す」というクエリが必要になりますが、関係性による検索が必要な場合はグラフDBのAmazon Neptuneの出番です。2022年10月にAmazon Neptune Serverlessの一般提供が開始されており、負荷予測の難しいワークロードでも使いやすくなっています。

工藤：データベースを複数使うという発想は、今まで自分の中になかったです。

高野：もちろんMySQLだけでもOKですが、AWSでは適材適所のサービスを使うことでそれぞれのメリットを生かす「Purpose-Built Databases」の考え方をおすすめしています。

工藤：データを書き込むときに、複数のデータベースにそれぞれ書き込んでいたらレスポンスが遅くなりそうです。最初はぼやきを表示するだけなので複雑なクエリは発生しませんが、パフォーマンスは優先したいです。

高野：たしかにリクエスト毎に同期的に書き込んでいると遅くなってしまいます。その場合は、例えばこんな構成はいかがでしょうか。

まずはDynamoDBだけに書き込み、成功したらクライアントにレスポンスを返します。DynamoDBの変更をDynamoDB Streamsに流し、そのイベントを非同期でLambda関数で受け取り、OpenSearch ServiceやNeptuneに書き込んでいくことができます。イベント駆動アーキテクチャと呼ばれるものになります。

工藤：この仕組みであれば、後からデータベースを増やすことも簡単にできそうです。つまり、この構成をAWSの上に作ればいいんですよね。AWSマネジメントコンソールは普段から使っています。

高野：マネジメントコンソールで手作業で作ってもいいのですが、開発者ごとに環境を作ったり、テスト環境や本番環境を分けて作ったり、何度も手作業で行うのは大変ですよね。

工藤：よく間違えるし、苦手な手順書もたくさん書かなければいけないです。

高野：アプリエンジニアの工藤さんにはAWS CDKをおすすめします。インフラ構成をコードで定義するInfrastructure as Codeのツールの1つですが、専用の言語ではなく、一般のプログラミング言語で書けるので使いやすいと思います。CDK Pipelinesという機能は、アプリのデプロイまで含めた、CI/CDパイプラインも簡単に作ることもできます。

工藤：コードで書くことができるのですね。プログラミングはすごく好きなので、CDKが気になります。

高野：CDKについてはこの後解説しますが、アーキテクチャとしては、こんな感じになりそうですね。もちろん、最初に決めたこのアーキテクチャに固執せず、良いものを見つけたらどんどん変更していくことをおすすめします。試しながら、より良いアーキテクチャを探せるのがクラウドのメリットです。

以上でロールプレイのパートは終了した。AWSのソリューションアーキテクトたちは日々このような議論を顧客と重ねているとのことだ。

Infrastructure as Codeはなぜ必要か

前述のとおり、ソリューションアーキテクトは技術的な観点だけでなく、ビジネスにおいて何が重要かといったところに目線を合わせて考えることがミッションとなる。その際、特にすばやい変化を求められるモダンアプリケーション開発においては、「Infrastructure as Codeが欠かせない」と、高野氏は言う。

Infrastructure as Codeは、「機械が処理できる定義ファイルまたはコードによってインフラストラクチャーの管理やプロビジョニングを行うプロセス」と言えるだろう。

そもそもなぜ必要なのだろうか。マネジメントコンソールでの手動操作、およびスクリプトベースで実行する場合に発生し得る不都合として、まず「人間が手作業で操作する」ことによってコストがかかり、ミスや手順書の解釈違いによるエラーが避けられない。

さらに、作業が手順書通りに正しく行われたかどうか、検証することは難しい。

リソースの状態による操作の変更は手作業ではアドホックにやってしまいがちだが、手順書やスクリプト上でエラー処理、ロールバックといった複雑な処理を網羅することが非常に難しい。それを解決するのがIaCの概念だ。手続き型におけるデメリットの裏返しになるが、手順書の作成やメンテナンスにかかるコストを削減し、人的ミスや環境のブラックボックス化のリスクを排除することができる。

AWS Cloud Development Kit（CDK）は、Infrastructure as Codeを実現するフレームワークのひとつで、JavaScript、TypeScript、Python、Java、.net、Goといった使い慣れた6つのプログラミング言語でクラウドリソースを定義できる。ツール固有の言語の習得に学習コストをかけることなく、またコードの補完や静的解析、ユニットテストなど、開発者が慣れ親しんだプログラミングの機能や技法を活用できることも大きな魅力と言える。

アプリ全体をコードで定義できるのもCDKの特徴の1つ。つまり、クラウドリソースだけでなく、関数やコンテナイメージなど、アプリ全体をまとめて管理できるのだ。

また、AWSのベストプラクティスに従った抽象化が利用でき、コード量と学習コストを削減できる点も大きなメリットと言える。もちろん、抽象化レイヤーから抜け出して、個別の設定にアクセスすることもできる。

ここで、CDKの仕組みを見ていこう。開発者は各言語のコントラクトライブラリを使って、好きなプログラミング言語でインフラ構成をコードで書いていく。それをAWS CDK Toolkit（CLI）に渡し、cdk deployコマンドを叩くと、書いたコードがAWS CloudFormationテンプレートに変換される。

AWS CloudFormationがこのテンプレートに従って必要なAWS APIを呼び出し、開発者が宣言したリソースをクラウドに作り上げていく。Lambda関数のコードやコンテナイメージというようなアセットも一緒にデプロイすることができる。こちらはCloudFormationを介すのではなく、AWS CDK Toolkitから直接デプロイされる。

コントラクトライブラリは、例えばTypeScriptであれば npm、Javaであればmavenでインストールする形になる。cdkコマンドは使っている言語によらず、すべてNode.jsのコマンドラインツールを使って実行する。

CDKの概念は次の図のとおり。CDKの最も基本的な要素がコンストラクトであり、これを組み合わせてAWSのリソースを定義する。コンストラクトはAWS CDKが標準で提供するAWS Construct Libraryを使って、ユーザーによる定義、配布が可能となっている。

コントラクトにはL1、L2、L3の3つのレベルがあり、L1はLow-level-constructでCloudFormationリソースと1対1で対応し、自動生成される。一番よく使うのはL2のHigh-level-constructで、デフォルト値やベストプラクティスを定義したAWSリソースを表すクラスだ。抽象化を含めることができるので、非常に使いやすくなっている。

さらに上位のレイヤーにはPatternsやL3コンストラクトと呼ばれるものがある。これは複数のリソースを含む一般的なパターンを表現するもので、例えば「aws-ecs-patterns.LoadBalancedFargateService」を使うと、Fargateで負荷分散されたECSのサービスを簡単に定義することができる。