クラウドソリューション事業部の原口です。
この記事は、Japan APN Ambassadors Advent Calendar 2022 の 2日目のエントリです。APN Ambassador って何？と言う方は、APN Ambassadorsってなんだ？2021年度版をご参照ください。
弊社の学生インターンシップはこれまで学生さんに実際に弊社まで来ていただき実施していたのですが、コロナの影響でリモートでの開催へと変更した経緯があります。この際、AWSサービスを使う事でなんとかリモートでの開催を実現できています。
今回はそんな弊社での学生さん向けインターンシップの中身とそれを支えるAWS技術をご紹介させていただければと思います。
学生インターンシップのカリキュラム
弊社のインターンシップ期間は3日間となっており、カリキュラムは以下のような内容となっています。
【1日目・座学】
PHPの基礎講座、Gitの基礎講座、AWSの基礎講座などを行います
【2日目・PHPプログラムハンズオン】
LAMP環境でPHP掲示板プログラムを作成し動かします。
あらかじめ最小限の実装がされたプログラムに対して追加の課題を発表し機能を実装していく形で進めます。
【3日目・AWS環境構築ハンズオン】
2日目で作成したプログラムをAWS環境にデプロイし、落ちないサービスとして運用します。
ELB – EC2 – RDS の構成で冗長化し、AutoScalingを使った台数の増減と自動復旧を一から構築し経験していただきます。また実際の運用におけるデプロイ手順の考え方などもレクチャーします。
カリキュラム対象はPHPなどのスクリプト言語を少し勉強をした事がある学生さんとなります。
これまではインターン前にあらかじめIDEの設定とPHP動作環境が構築された参加人数分のMacBookProをご用意し、3日間講師がつきっきりで見ながら進めるという形をとっていました。
しかし、リモートになる事で同じ場所で作業ができなくなる点において、以下のような問題が発生しました。
リモートインターンシップの課題
基本的にはビデオ会議(zoom)で基礎的なコミュニケーションは行えますが、以下の問題が出てきました。
問題① PHP開発環境の準備をどうするか
プログラムのカリキュラムとしてはGitHubでPHPプログラムを準備しており、それらはDockerで動かしていました。
リモートでの開催となると、PCのレンタルが出来ないので参加者は自身のPCを使っていただく事になり、少なくとも Git, Dockerのインストールをお願いする事となってします。「そんな事を強制していいのだろうか、」という懸念がありました。
また、参加者のPC環境がWindowsやMacOSやLinuxなど違いがあると、思わぬトラブルがあったとき本来のカリキュラムが進めらなくなるのでは？という問題がありました。
問題② 参加者さんの現在の状況がわからなくなりそう
これまでは物理的に同じ場所でしたので、参加者がどこで詰まっているのかなどがすぐにわかりました。しかし、リモートになると参加者のPC上で起きたトラブルシュートが難しくなるという課題がありました。
問題③ AWS環境を監督できない状態でお渡しして大丈夫か？
これまでもAWSアカウントは参加者の人数分ご用意して構築作業をお願いしていましたが、物理的に監視ができる状態でしたので問題のある設定を実際に確認する事ができました。
学生さんはクレジットカード登録などの敷居の高さから、はじめてAWSを使う方も多いため、可能な限りはじめてのAWS構築という形を体験していただきたくルートアカウントをお渡ししてスタートしていたのですが、これらは物理的な監視があったからこそ実現していました。
が、リモートによるリスクを担保できるのか、、、という懸念がどうしてもありました。
課題の解決策
解決策① AWS Cloud9の利用
Cloud9はAWS上のIDE(統合開発環境)です。詳細なサービス概要はここでは説明しませんが、以下の点がリモートインターンをする上で非常にマッチしていました。
1・ブラウザさえあればエンドユーザー環境に特別なソフトを入れずに開発(カリキュラム)をスタートできる
2・リアルタイムで他のユーザーとコラボレーションできる。
3・実態はEC2(Amazon Linux 2)なのでわりとインフラ的な構築をわりと自由に行える
4・30分使われていないと自動で停止しコスト削減ができる。(再び使いたい時もブラウザで接続するだけで自動で立ち上がる)特に「リアルタイムで他のユーザーとコラボレーションできる」という機能が素晴らしく、インターン生のコーディングの様子をリアルタイムで確認する事ができます。googleスプレットシートを同時に編集してるイメージですかね。
実際のインターンの様子
実際のインターンではこうやって大きなモニターに映しながら「ああーこう来たかー！」「なるほど、面白い実装だ」なんてメンター同士でキャッキャうふふしながら楽しんでいます。カーソル位置まで共有されますので、「悩むよねーここは…」なんて事まで把握できて、正直リアル開催の時よりもインターン生の現状がわかるといってもいいかもしれないです。
こちらの導入で①,②の課題は解消できました。
Cloud9ですが、弊社のカリキュラムはdocker compose up -d で一式環境PHP(Apache) + DBが立ち上がる形としているのでCloud9でもその構築をしてあります。
ですが、すでに初期状態でGitやDockerが入っていますので作業としては/home/ec2-user/environment へカリキュラムのリポジトリをgit cloneしておき、docker composeコマンドを利用できるようにインストールしておくくらいの作業でした。
mkdir -p $HOME/.docker/cli-plugins
curl -L "https://github.com/docker/compose/releases/download/v2.12.2/docker-compose-$(uname -s)-$(uname -m)" -o "$HOME/.docker/cli-plugins/docker-compose"
chmod +x "$HOME/.docker/cli-plugins/docker-compose"
docker compose version
あとは自動起動させるためにchmod 755 /etc/rc.d/rc.local で実行権限をつけた後に雑に以下のような記述としています。
cd /home/ec2-user/environment && docker-compose up -d
ソースはgit checkoutで戻せますし、docker compose down -> up -dしてやればDBも初期化できるので同一環境を使い回して運用しています。
ちなみに、これらのシェルの作業もブラウザ上のターミナルから実施できて素晴らしい。。
解決策② AWSアカウントをどう守るか
ルートアカウントをご経験の少ないリモートの学生さんたちへお渡しするのは、漠然とした不安もありましたが、実際のところこの心配はどこからくるのかな？
と考えた結果「悪意がある無いに関わらず、利用によって高額な請求が来てしまう可能性」と定義しこちらを防ぐ事を考えました。
特に、最低利用期間があり高額な AWS Shield Advanced なんて契約された日には僕の首が飛びかねません😩
AWSではルートアカウントは唯一無二のユーザーとしてフルアクセス権限がありそれらを制限する事はできません。
しかし、AWS Organizations として構築した組織の子アカウントであればSCP（サービスコントロールポリシー）という機能を使って子アカウントのルートユーザーの利用に制限をかける事が可能となります！
全体としては以下のようなAWS Organizations構成としました。
AWS OrgannizationsにてOUと呼ばれる組織単位を作成し、その中にインターン生が実際に使うAWSアカウントを作成していきます。
SCPはこのOUに対してアタッチしていきます。
実際のポリシーは以下のような形としています。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Statement1",
"Effect": "Deny",
"Action": [
"aps:*",
"a4b:*",
"chime:*",
"cloudhsm:*",
.
.
(中略)
.
.
"shield:*",
"savingsplans:*",
"snowball:*",
"snow-device-management:*",
"storagegateway:*"
],
"Resource": [
"*"
]
}
]
}
インターンでは明らかに使わないものは利用できないように制限を入れています。現状、上記設定で問題となった事はありませんが、SCPでは「インスタンスタイプの制限」や「利用できるリージョンの制限」などもできますのでルートアカウントに限らず誤作業による無駄な料金発生を防ぐ事ができますね。
ただし！SCPでは制限ができないAWSサービスもありますのでこちらの点は注意が必要です。以下、公式ドキュメントより引用です。
SCP を使用して次のタスクを制限することはできません。・管理アカウントによって実行されるすべてのアクション・サービスにリンクされたロールにアタッチされたアクセス許可を使用して実行されるすべてのアクション。・root ユーザーとして Enterprise サポートプランに登録する・root ユーザーとして AWS サポートレベルを変更する・信頼された署名者に CloudFront プライベートコンテンツの機能を提供する・Amazon Lightsail メールサーバーおよび Amazon EC2 インスタンスの逆引き DNS をルートユーザーとして設定する・一部の AWS 関連サービスでのタスク ・Alexa Top Sites ・Alexa Web Information Service ・Amazon Mechanical Turk ・Amazon Product Marketing APIhttps://docs.aws.amazon.com/ja_jp/organizations/latest/userguide/orgs_manage_policies_scps.html
今回の使い方ですとAWSサポートレベルの変更やEnterpriseサポートプランの登録が結構痛かったのですが、後者は初動が問い合わせベースがスタートだったのでリスクは少ないと判断しました。
実は1日で上記環境をアーキテクト！
コロナ禍となった2020年2月頃から現在の構成で2年間、何度かリモートインターンを実施していますが、大きなトラブルもなく、学生さんの満足度も高いように感じています(多分…)。
実はこの環境は突然、緊急事態宣言が発令されて翌日のオフラインでのインターンができない！となった事がきっかけで考えられました。どうしよう…と悩みながらも半日で考えられて実装し、翌日、無事にリモート実施された経緯があります。
今では当たり前になっていたのですが、改めて「すぐに使える」というAWSの威力を再認識しました。
以上です。