こんにちは、株式会社ACESのソフトウェアエンジニアの稲田です。 ACESは画像認識アルゴリズムに強みを持つAIスタートアップです。ACESでサーバエンジニアはどんな仕事してるのだろう？という疑問に答えるべく、ACESのソフトウェア技術関連の発信をしていきたいと思っております。 この記事では、ACESのセキュリティの根幹を支えるネットワークインフラを紹介させて頂きます。
ACESでは保険/スポーツ/報道/小売/建設/製造業など様々な顧客の課題に対してDX提案/取り組みを行っており、抱えているプロジェクト数も多くなっております。 そこで、当たり前の話ですが、
- 顧客毎のデータをセキュアに保つ
- オペミス等で誤って他の顧客の環境を壊さない
を満たすデータ管理が必須です。 ACESではこれを実現するため、以下のインフラを構築しております。
顧客毎にAWSアカウントをわけることで、AWSがクラウドで提供するセキュリティ責任がそのままダイレクトに顧客データに対して担保されることを顧客にわかりやすく説明することができ、安心してデータをお預け頂くことが出来ます。 また、顧客のIT内部統制などのコンプライアンス上の観点から、データへのアクセスログ等の監査ログの取得が必須となる場合にも、AWSアカウントをわけることで比較的簡単かつ柔軟に対応することが可能となります。
ここからは技術的な話にフォーカスして、主にサーバエンジニア向けに「セキュリティを担保しつつ認証や監視等の共通基盤はまとめる」部分をACESではどうやって実現しているか、システム事例紹介させて頂きます。
技術概要
ACESでは前述のインフラを構築するためにAWS OrganizationsとAWS Transit Gatewayというサービスを活用しています。AWS Organizationsを使って複数のAWS アカウントを管理しつつ、認証や監視等の共通基盤は専用のAWSアカウント(shared serviceアカウント)に集約しています。そして、個別のアカウントとshared serviceアカウントの通信ネットワークをAWS Transit Gatewayによって接続しています。利用シーンは大きく2パターンが存在しており、
があります。構築の中心となるAWS Transit Gatewayを説明した後に、これらの2パターンのネットワークの構成の詳細について説明していきます。
AWS Transit Gateway とは
まず、構築の中心となるAWS Transit Gatewayについて説明します。AWS Transit Gatewayは、AWSアカウントをまたぐネットワーク(VPC)やオンプレミスを含めた異なるネットワークを一つの中央ハブで接続して通信、通信制御出来る仕組みです。特徴として以下の項目が挙げられます。
- VPC間接続を簡単に管理するためのシンプルなリージョナルゲートウェイ
- 数千のVPC, VPN, DirectConnectを接続可能
- アタッチメントごとのルーティングを可能にするルーティングドメインのサポート
引用元：[AWS Black Belt Online Seminar] AWS Transit Gateway
ネットワークは合理化され、スケーラブルになります。AWS Transit Gateway は、各 VPC または VPN との間のすべてのトラフィックをルーティングします。すべてのトラフィックを 1 か所で管理して監視できます。
引用元：AWS Transit Gateway（VPC およびアカウント接続を簡単にスケール）
インフラ構築方針
構築の方針を技術的にブレークダウンすると以下のような項目を実現することになります。
- インフラ構築のリードタイムを最小限にする
- アルゴリズム単体利用からフルセットサービスまで柔軟なユースケースに対応できるインフラ構成を実現する
- shared serviceアカウントを活用して共通利用可能な機能を管理する
ネットワーク構成
アルゴリズム単体利用構成
まず、学習済のアルゴリズムをAPI利用する場合ですが、shared serviceで基本的な認証や利用ログ等を含む共通的なFront画面とAPIを提供しており、shared serviceからアルゴリズムリポジトリテーブルを参照してアルゴリズムのendpointを特定しTransit Gatewayを経由してアルゴリズム推論を実行します。
ネットワークの簡単な説明を致しますと、shared serviceアカウントのネットワークを10.0.0.0/16、顧客アカウントを10.1.0.0/16としてTransit Gatewayで接続して、必要なネットワーク(VPC)間のみ通信可能となるようルーティングテーブルを設定します。個別サーバへのセキュリティは基本的には必要なセキュリティグループに所属していない場合はアクセス不可となり、セキュリティグループを作成しアクセス権を付与して担保します。 顧客が増えますと10.2.0.0/16、10.3.0.0/16とネットワークが増えていきますが、各々の顧客のネットワークはルーティング上、相互参照せず、shared serviceとのアクセスのみ可能となっています。
フルセットサービス構成
推論だけではなくて何らかの個別のドメインデータを持ってサービスを提供する場合はオーソドックスに顧客アカウントでサービスを構築します。この場合はshared serviceの認証や利用ログ等マイクロサービスで提供される機能を必要に応じて利用できます。ここまでくるとAWSアカウントをまたいだ認証情報を持っていなければ、Transit Gatewayは使わず、顧客アカウント内に全部機能を持ってしまって顧客アカウント内でネットワークは閉じてしまっても良いです。
各々の要素はInfrastructureAsCodeでテンプレート化できます。InfrastructureAsCodeでテンプレート化はエンジニアみんな大好きの楽しいお仕事です。
所感
スタートアップのスピード感を保ちながら、守るべきセキュリティーは担保するという課題を、大きすぎる仕組みにならず適切な手早さで実現できている構成だと思います。
顧客毎にAWSアカウントをわけると一言で言ってしまえば簡単ですが、API提供する場合個別AWSアカウントにAPI認証基盤を各々作るのか（例えば認証用に個別にbackendのDBの構築が必要な場合、DBの管理やDBのインスタンス費用を個別に持つのが果たして適切なのか）、実際の構築作業をはじめると多くの細かな問題と作業に悩まされてしまいます。 すぐ顧客にサービスを提供したいというビジネスのニーズは、InfrastructureAsCodeでインフラをコードでテンプレート化することで実現可能にも思えますし、実際できなくはないですが、NATや運用系のリソースを含めたフルセットのテンプレートはなかなかに重く、出来れば各々のビジネスで使うAWSアカウントで作成するリソースセットは最小限の依存関係に留め、誰でも理解できるレベルの小さなテンプレートにしたいものです。
また、ネットワーク周りのインフラは歴史ある組織だと既にVPC Peering等で実現している部分があったりで、それをわざわざ作りなおすかというとなかなかタスクの優先度の観点で後回しになりがちで、AWS Transit Gateway使って今どきのいい感じのシンプルなネットワークインフラを作ってみたくてもなかなか機会がない、組織が微妙に大きすぎてネットワークインフラの再構築はなかなか手がでないとかあったりするのではないでしょうか。 その点、スタートアップだとまっさらなキャンパスでワクワクしながら今どきのAWSのネットワーク構成を構築することができたりします。まだまだまっさらなキャンパス(=最新の技術を使ってみることでスキルが身に付きエンジニアとして成長する領域)はいっぱいあります。
ACESではAWSマルチアカウント構成をAWS organizationsとAWS Single Sign-On構成で実現していますが、こちらのご紹介はまたの機会に。
おわりに
この記事では、ACESのAWSマルチアカウントのネットワークインフラ構成をご紹介しました。 ACESでは、積極的に採用を行っています。ACESに興味をもっていただいた方がいらっしゃいましたら、お気軽にご連絡下さい！
ACESのリクルートページはこちら↓
