AI Hackathon を運営してみての気づき

この記事は SB-AI Advent Calendar 2019の10日目の記事です。

はじめに

先日softbankでAIハッカソンを行い、その際の学びを備忘録も兼ねて投稿します。
※AIの技術ではなく、メインはAWSを利用したインフラ環境の話です。
私自身、AI開発に従事したことも無ければインフラエンジニアでもないので、初めてのことばかりでした。
その点を踏まえて、心優しい目で見てもらえると嬉しいです。

AIハッカソンの悩み

国内でAI関連のハッカソンを開催しようとすると一番最初にネックになるのが、データの確保です。
普段触れることのできるpublicなデータではリッチ感が出ず、
かといって企業保有のデータを利用するのは、情報管理の上でも難しい。
このジレンマから魅力的なハッカソンを運営をするのは中々ハードルが高いです。

今回のテーマ

今回のテーマは可能な限りデータを外部に持ち出すことに制限をかけ、
データ提供側の心理的負担を取り除く為に考案したインフラ設計です。
※これがベストな環境だとは思いませんし、もっと良いアーキテクチャを考えられる方是非教えて下さい！

前提

1. 参加者規模：5人×20チーム(100名)
2. データ形式：テーブルデータ（マスク済み）
3. データのローカルPCへの移行不可
4. データのパブリックアクセス環境下への転送不可

構築

構成図

まずはじめに、最終的にどのようなアーキテクチャになったかの構成図を貼っておきます。

図には記載されていませんが、subnetはnetwork ACLを設定しておき、外部ネットワークとの切り離しをワンポイントで設定できるようにします。

このように構築することで、ネットワーク隔離の基盤まで容易した上で、EC2、RDSはworkspaces上からのみアクセスできる環境を実現しています。

構成内訳

サービス	台数
VPC	1
Internet Gateway	5
Nat Gateway	5
public subnet	5
private subnet	40
EC2	20
RDS	20
Directory Service(Simple AD)	20
workspaces(win10)	20

次からは何故その数を用意したかを具体的に話していきたいと思います。

VPC

こちらは問題ないですね。
複数用意する必要性もなかったので1つで済ませています。

Internet Gateway

InternetGatewayは外部環境へのアクセスのために必要ですが、
今回は外部へのアクセスは基本禁止なので、最低限しか用意していません。
※上限緩和申請しない限りは5つが限界値です。

構成図には現れていませんが、各Gatewayにprivate subnetを8つ割り当てています。

Nat Gateway

private subnet内のインスタンスから外部ネットワークにつなぐために、public subnetとの疎通に利用しています。
public subnetと同じ数必要なので、5つとしています。

EC2

各チーム1台、計20台のインスタンスとしました。
ハッカソンの特性上、チーム人数分必要との声もありますが、今回はそこには触れません。

RDS

EC2と同様に各チーム1台×20チームです。

Directory Service

workspacesを利用するための基盤です。
workspacesを各チーム1台利用するため20用意します。

workspaces

EC2、RDSと同様に各チーム1台。

注意点

ここからは本環境を構築する時の注意点を記載していきます。
実際に作成してみて、上手くいかなかった事は忘れないように残しておきたいですね。

各サービスの上限数

これは本当に悩まされました。
皆さん、中大規模構築する際には一度は必ずココをみましょう。
AWS サービスクォータ

わかりやすいように各サービスを容易する数と、上限を表にまとめます。

サービス	台数	上限
VPC	1	5
Internet Gateway	5	5
Nat Gateway	5	5
public subnet	5	200 ※1
private subnet	40	200 ※2
EC2	20	1152 vCPUs ※3
RDS	20	40
Directory Service(Simple AD)	20	10
workspaces(win10)	20	1

※1 - privateと共有
※2 - publicと共有
※3 - インスタンス数ではなくvCPUsの利用数でのカウント　詳細

赤字で書いてあるとおり、2つのサービスが上限に引っかかっています。
ちなみにこの2つのサービスの上限緩和のためには米国側への申請が必要らしく、他のサービスよりも申請から緩和までのリードタイムが長いです。
とはいえ1日で対応いただきました。AWSの担当の方には頭が上がりません。迅速な対応ありがとうございます。

RDS→workspaces→EC2の順に構築すべし

何故なのか。
これはavailability zoneの特性に由来します。

RDSはavailability zoneを跨いでの利用が可能です。
問題はEC2とworkspacesです。

workspacesは作成時にDirectory Serviceで設定した異なるavailability zoneのsubnet2つの中からランダムで生成されます。
EC2は指定したsubnetに構築されます。

ですので、workspacesを構築し、どちらのavailability zoneに生成されたかを確認し、そのavailability zoneに対応するsubnetにEC2を構築する必要があります。

これにハマってしまって、EC2を30台ほど再作成する必要がありました。。。

各種サービスへのアクセス情報管理

EC2はssh接続するために秘密鍵を利用します。
秘密鍵は予め各チームのworkspaces上に置いておきます。
それ以外のworkspaces、RDS、EC2のアクセス情報を各チームに送り、準備は完了です。

運用

ここからは構築した環境を参加者にどのように利用してもらったかの解説です。
データの取り回し的にもココはかなり気を使いました。

スケジュール的には以下のような形です。

開催前準備期間：5日ほど
環境へのテーブルデータ投入：開催当日朝
外部ネットワークへのアクセス遮断処理：データ投入後〜開会前
一時的な外部ネットワークへのアクセス許可：ハッカソン期間中

開催前準備期間：5日ほど

データの投入後は外部ネットワークへのアクセスを遮断するので、
ハッカソン開催前に環境をお配りし、ライブラリやツールインストールなどの環境整備をしていただきました。

ココはもうちょっと長めに期間を設けても良かったと思います。
短くても1週間、欲を言えば2週間程あると良かったかなと思っています。

環境へのテーブルデータ投入：開催当日朝

当日朝、workspaces上にcsv形式でデータを投入していきます。
ココはデータ提供先の方々立ち会いのもと、データの取り扱いに注意しながら作業しました。

外部ネットワークへのアクセス遮断処理：データ投入後〜開会前

設定してあったnetwork ACLの設定で外部環境とのアクセスを遮断します。
ここで、

• チームごとの作業環境
• テーブルデータ

が揃ったことになります。

一時的な外部ネットワークへのアクセス許可：ハッカソン期間中

これもデータ提供元に気を使った対応です。
ハッカソン期間中にツールやライブラリ、外部データを追加でダウンロードしたいといった要望が出てくるのは想定していました。
ですので、技術スタッフ立ち会いのもと、データを外部へ持ち出す行為を行っていないかチェックしながら、都度network ACLの設定を書き換え、必要な時のみ外部ネットワークへのアクセスを許可しました。

想定はしていたものの、予想以上に件数が多かったのと別のトラブル対応などがあり、技術スタッフ不足になってしまいました。。。
この規模なら少なくとも5人、欲を言えば10人程、技術スタッフが待機していても良いかもしれません。

最後に

ここまでアーキテクトと運用に絞ってお話してきました。
もっと、各サービスの立て付けの所を詳しく説明しても良かったのですが、長くなりそうなので今回は割愛します。

もし、知りたい方がいればコメントいただければと思います。
こちらはできる範囲で個別に回答させていただきます。

最後になりましたが、長文記事を最後まで読んでいただきありがとうございます！