「単一のアカウントを分けたい」「CI/CDを簡単にやりたい」　スタートアップに“あるある”のAWS相談の解決策

自己紹介

松田和樹氏（以下、松田）：「[AWS Startup ゼミ]よくある課題を一気に解説！御社の技術レベルがアップする 2021」秋期講習と題して、私と齋藤の2名でお届けします。

最初に自己紹介を簡単にします。私は松田と言います。ふだんはスタートアップ企業専任のソリューションアーキテクトとして、スタートアップのお客さまの技術的な支援やビジネスモデルや採用に関してなど、スタートアップならではの多岐にわたる相談を受けて支援するポジションの人間です。

私自身もAWSに入る前はスタートアップでエンジニアとして働いていたので、そういうバックグラウンドを活かしながら、スタートアップのお客さまを支援しています。では齋藤さん、お願いします。

齋藤祐一郎氏（以下、齋藤）：私もスタートアップソリューションアーキテクトとして働いている、齋藤祐一郎と言います。松田さんと同じ部署で、お客さまの技術支援を担当しています。特にアーリーステージ、立ち上げたばかりのスタートアップの企業およびFinTech企業を担当しています。（※登壇時点。現在はFinTech専任）それまでは、20年ほどバックエンドのソフトウェアエンジニアおよびITインフラエンジニアを担当していました。どうぞよろしくお願いします。

「Startupゼミ、よくある課題シリーズ」とは何か

松田：よろしくお願いします。今日はこの2名でセッションを進めたいと思っています。コンテンツの中身に入る前に、「Startupゼミ、よくある課題シリーズ」とは何なのかという話を少しします。

自己紹介にもあったのですが、我々AWSのスタートアップチームは、日々スタートアップのお客さまから、非常に多くの質問や相談を受けています。その中で、技術的な課題や傾向などが見えてきます。そのため、定期的にこのような秋期講習、春期講習でセッションをして、そのタイミングで「最近はこの質問がある」という、あるあるな課題をまとめて紹介しています。

もちろんセッションの中でより詳しく、細かく、具体的に紹介や解説ができるとベストなのですが、やはり時間的な制約もあるので、お客さまの「こういうことを実現したい」という課題に対して、どう考えてアプローチしていけばいいのかという、思考フローや思考パターンをメインに紹介します。

さらに、その思考パターンで考えた時に、何を参照すればいいのかがわかるセッションや資料構成になっています。このセッションを見た後も、ぜひ逆引き辞典のように利用してもらえるといいのではないかと思います。

（スライドを示して）これまで定期的にゼミをやっているので、資料も上がっています。今回の資料自体も後ほど公開するので、検索してもらったり、ハイパーリンクになっているので、ぜひ過去の資料も参照してもらえると、より技術レベルがアップできるのではないかと思います。

というところで、本編に移っていきたいと思います。今日のアジェンダはこちらの4つです。前半2つを私からお届けして、後半2つを齋藤からお送りする想定となっています。

相談1：単一のAWSアカウント分けたい

それでは1つ目です。（スライドを示して）こちらのテーマについてお話ししようと思います。

みなさんの中にも思い当たる方がいるかと思うのですが、実際に多くの相談をもらっています。

どういう相談かというと、最初に作った単一のAWSアカウントで開発を始めてサービスを提供する時に、そのアカウントに本番環境も開発環境も入っていて、分ける工数がなかなか割けなかったり、そもそもどうやって分ければいいかわらず、最初に作ったAWSアカウントがどんどん肥大化していく、ということです。

あるいは、分けてみたはいいけれど、アカウントがどんどん増えて、むしろかなり大変になり「これはどうしたらいいんですか？」という相談も受けています。お客さまからもらう課題は「このアカウントをどうしたらいいか」ということですが、私たちは「本当にしたいところは何かをよく考えるように」と、お客さまに案内することが多くあります。

これは何を言っているかというと、課題は「アカウントを分けたい」ということだと思いますが、実際にやりたいこととしては、「現在動いているプロダクトの本番環境に影響を与えることなく、ガバナンスや運用を改善したい」ということです。

あるいは、今回単発で分割するだけではなく、将来的に管理するAWSアカウントが増えるようなシチュエーションにも備えたいというところまで含めて、本当にやりたいことなのかをよく確認しています。

課題に対するアプローチとして、「こういうステップで考えて進めていくといいのではないか」ということを、1、2、3のステップで案内しようと思っています。

本日は4つのテーマを取り上げますが、基本的にいただいた課題に対して、本当にしなければいけないことは何なのかを確認して、それに対してどういうふうに進めるかというのを、3ステップで話を進めていきます。

ステップ1：移管先のAWSアカウントを準備する

それでは、1つ目のステップです。移管先のAWSアカウントを用意します。（スライドを示して）こちらが最初に作ったAWSアカウントに複数の環境が入っているという概念図、イメージ図です。

今メインで作っているプロダクトAの開発と本番が既に相乗りしています。さらに、（この環境には）パイロットで今まだテスト中のものや、新規プロダクト開発中のものがあります。とりあえず今はAWSアカウントを持っていて、その中で開発を始めたという、比較的あるあるなシチュエーションだと思います。

この動いている環境を分けていくことが必要になると思います。やらなければいけないことはシンプルです。これらのリソースを移管しなければいけないので、移管先のAWSアカウントを用意するということです。

アカウントを増やすことに関していうと、普通にAWSのホームページからサインアップして作ればいいですが、単純にAWSアカウントを増やすと、管理するものが増えて大変になることは、みなさんも想像がつくと思います。そこに対応して管理を容易にするために、我々はAWS Control Towerというサービスの利用を推奨しています。

AWS Control Towerを利用することで、複数のアカウントがあるマルチアカウント環境の整備が非常に簡単にできるようになるので、こちらをうまく使っていただくようにお勧めしています。

通常、OrganizationsやAWS Single Sign-Onのサービスをうまく使って、アカウントを管理することになると思います。これらのサービスを自分で調べて設定するのはけっこう大変ですが、それをControl Towerを使うと簡素化して設定できるので使ってください、というお話です。

ステップ2：影響の少ないところから移管する

松田：では2つ目のステップです。これも比較的言っていることはわかりやすくシンプルで、「本番環境への影響度が低いものから移管しましょう」ということです。みなさんも慣れていればぜんぜんいいのですが、そうではない場合、移管にあたっていろいろなトラブルや試行錯誤はあると思います。そのため、できるだけ影響がないところからやりましょうということは、今回の件に関わらず、よくあるケースかと思います。

（スライドを示しながら）今回の例だと、「プロダクトAの開発環境を移しましょう。あるいは、プロダクトBの開発環境を移しましょう。」と順番に移していくと、最終的にもとのアカウントにメインのプロダクトの本番環境だけが残るので、非常に安全に移せるという考え方です。

もちろんInfrastructure as Code、環境のコード化などが実現できていれば、これらの移行もCloudFormationやTerraformを流し込むだけで実現できて非常に簡単になるので、そういった観点でも環境のコード化はけっこう重要かと思います。

1点、注意点は、環境のコード化ができていて、比較的さらっと移行できたお客さまであっても、移管されるのは環境だけで、データは別途移管が必要なので注意してもらえるといいと思います。

今日は、検証環境から移す話をしています。しかし、場合によっては、既存の本番環境がけっこうぐちゃぐちゃだったり、あるいはVPC（Virtual Private Cloud）の中で利用しているアベイラビリティーゾーンが2つで、もうすでにサブネットを使いきっているとか、3つ目のAZを使いたいとか、環境が意図に沿ったものになっていなくて作り直したいケースもあると思います。

そういう場合に、他のアカウントに本番環境を移して再構築するお客さまもいますが、これはマストではありません。

ステップ3：VPC同士をつなぐサービス・機能を活用する

最後です。先ほど、アカウントを移す話をしましたが、場合によっては既存の環境のデータベースに接続が必要とか、APIを叩かなければいけないとかで、ネットワークの疎通が必要なことがあると思います。

純粋にアカウントを分けてしまうと通信ができなくなり、今の自社のサービスで動かないケースもあると思います。そういう場合は必要に応じて、VPC PeeringやTransit GatewayといったVPC同士をつなぐサービス、あるいは機能をうまく活用してもらうといいのではないかと思います。

（スライドを示して）こちらはあくまでサンプル図ですが、既存の環境にデータベースが残っていて、移管した先の別のサービスから、歴史的経緯によってデータベースを直接参照しなければいけないようなケースがまだまだあると思います。

移行のタイミングだけ暫定対応としてVPCをつないでみるときに、1対1の対応状況であればVPC Peeringのような機能が利用できるし、あるいは1対1ではなくて、AWSアカウントが3つか4つあって双方に接続しなければならず、一つひとつPeeringするのが大変な場合であれば、Transit Gatewayのほうが適切というケースもあるかと思います。

あるいは、スタートアップの場合、データセンターと契約しているケースはそれほど多くないと思いますが、自社のオフィスやデータセンターとVPNなどを接続している場合に、環境が増えるとそれぞれに張らなければいけないことがあります。アカウントを分けてVPCを分けたとしても、一括管理するのにTransit Gatewayを利用できるので、覚えておくといいと思います。

ここまでがVPC PeeringとTransit Gatewayという、基本的に双方向で通信可能なローカルIPアドレスレベルで通信ができるものですが、通信が片方向で必要なケースもあると思います。例えば、既存の環境にAPIのエンドポイントがあって、これを叩ければいいというケースです。

そういった場合は、Private Linkという機能を使うことで、エンドポイントの足だけを他のVPCやAWSアカウントに対して出せるので、このあたりをうまく使い分けるといいのではないかと思います。

（スライドを示しながら）3ステップは以上のような感じですが、今回このセッションでは、参考資料や事例をきれいにまとめているので、このあたりもチェックしてもらえるといいのではないかと思います。

相談2：CI/CDを簡単にやりたい

松田：2つ目です。「CI/CDを簡単にやりたい」という、こちらもよくもらう課題です。

「CI/CDの環境を整備したいがよくわからない」とか、「既存環境へのつなぎ込みが難しい」という課題をいただきます。

やりたいけれどもやり方がわからない、知見が足りなくて足が重いという話です。本当にやりたいことは何かというと、もちろんデプロイを自動化して、できるだけヒューマンエラーなどを減らしたいという話もあると思いますが、CI/CDをとおして、プロダクトの品質や開発効率を上げたいということがメインの目的になるかと思います。

（スライドを示して）「CI/CDを簡単にやりたい」というセクションで使える思考フローとしては、この3ステップになるかと思います。

3ステップに入る前に、前提として「CI/CDとは」について軽く触れようと思います。CI/CDを直訳すると、“継続的インテグレーション/継続的デリバリー”です。（スライドを示して）CI/CDはこちらにも書いてありますが、特定のサービスや、ツール、技術を指しているわけではなく、アプリケーション開発を効率化する仕組みや開発手法のことです。

あくまでCI/CDのパイプラインのイメージですが、Git Repositoryや、ソースコードのバージョンを管理しているところから、コードの変更や新しいバージョンのリリースがあった時に、それを検知して自動的にテストやビルドを行い、その結果、問題がなければ自動でデプロイが走ります。

デプロイ先もコードのブランチなどに連動して、本番環境や、ステージング環境、テスト環境などに接続するのを自動的にやることを総称して、CI/CDと呼んでいます。

ステップ1：自動デプロイ組み込み済みのプロダクトを使う

ではステップ1つ目ですが、これはけっこうシンプルです。自動デプロイが組み込み済みのプロダクトを使うということです。（スライドを示しながら）ここにも書いてありますが、AWSにはGitHubと接続するだけでデプロイ可能なサービスがいくつかあります。

これをうまく使うと、基本的に出来合いの機能を利用するので、非常に品質の高い自動デプロイの仕組みが利用できます。1つ目はAWSのAmplify Consoleというサービスです。こちらは静的サイトや、SPA（Single Page Application）のフロントエンドのホスティングに利用ができるものです。

どういうふうに使うかというと、GitHubとAmplify Consoleを連動する、あるいは連携する。最初にOSで接続すると、このPushやMergeやプルリクエストを作成したタイミングで通知が送られてくるので、それを契機に、Amplify Consoleは内部でCDN（Content Delivery Network）にソースコードを展開します。

（スライドを示して）特徴的なのは、一番下にあるPR（プルリクエスト）を作成した時に、それをプレビューするための環境も用意できます。環境によって認証をかけたいケースもあると思いますが、開発者のみがアクセスできるように認証をかけられるので、ぜひうまく使ってもらって、本番環境、検証環境につなぎ込めば非常に簡単になるのではないかと思います。

もう1つは、AWS App Runnerで、サーバーサイドのアプリケーションを動かす時に使えるコンテナ系のサービスです。こちらも同様にGitHubのリポジトリとApp Runnerを認証して接続します。

（スライドを示しながら）そうすると、PushやMergeのようなソースコードの変更を検知すると、App　Runnerの中でこのようにコンテナをビルドして起動し、Load Balancerにぶら下げるので、基本的に接続してソースコードの変更が行われれば、勝手にエンドユーザーがアクセスできる環境までデプロイしてくれます。

この動き方でサポートされているのは、Python3とNode.jsの12だけであるのが注意点です。

その他のランタイムについては、GitHubが直接接続するのではなくて、コンテナイメージをご自身で持ち込むことが必要です。具体的には、AWSであればAmazonにはECR（Amazon Elastic Container Registry）が用意されているので、イメージレジストリとして連携することで利用できます。

GitHubとの接続はどうするのかというと、ツールは何でもいいのですが、GitHub ActionsやAWS CodeBuildなどのビルド系のサービスでどこかにイメージをビルドして、イメージをPushするところだけ自身で構築する必要があるので、ここだけ注意するといいのではないかと思います。

ステップ2：デプロイパイプラインを簡単に構築できるものを使う

ステップの2つ目です。1つ目のトピックで、組み込み済みのプロダクトを使おうと話しましたが、使えないケースもあると思います。そういう場合は、オープンソースやAWSが提供するツールの中で、デプロイパイプラインを簡単に構築できるサブコマンドや、オプション。ほかには、コンストラクトが提供されているものをうまく使いましょう。

例えば、AWS Copilot CLIです。こちらはAmazon ECSやAWS App Runnerを利用したコンテナアプリケーションを、実行できるファイルに簡単に構築できるCLI（Command Line Interface）ツールです。コマンドラインオプションの中に、デプロイパイプラインを簡単に構築する時の雛形を生成するコマンドがあるので、それをうまく使ってもらえると、コンテナアプリケーションのCI/CDに関する知見がなくても、Copilot CLIが敷いたレールにのって、簡単に実装できます。

サーバーレスアプリケーションの場合は、AWS SAM Pipelinesを使います。AWSのCI/CD系のサービスは、CodePipelineが一般的によく知られているかと思います。SAM Pipelinesはコマンドラインで雛形を作成する際に、対話形式でどの環境で動かすかを選ぶと、JenkinsやGitLab CI/CD、あるいはGitHub Actions向けの雛形も生成できる柔軟性を兼ね備えているので、お好みの環境で使えるところが非常にうれしいのではないかと思います。

最後に、CDK Pipelinesです。こちらは任意のプログラミング言語で、クラウドフォーメーションで構築可能なアプリケーションを実装できるものです。CDKの中でPipelinesを簡単に実装できるコンストラクトが用意されているので、それをうまく使ってもらえると、記述量が非常に少なくデプロイパイプラインを組めます。

これらのツールがバチッとフィットするケースもあれば、作られた雛形に少し手を入れることでフィットするケースもあるので、うまく活用するといいのではないかと思います。