はじめに

こんにちは、hengeです。
今回は、前回に引き続き弊社の新入社員研修についてご紹介いたします。第2弾の本記事ではAWS実践提案道場による研修についてまとめました。
「実践」「道場」…何やらレベルが高そうな単語がちらほらと目に入って不安ですが、頑張っていきましょう！

ちなみに、前回の新入社員研修紹介ではWordPress構築の研修を取り扱いました。
本記事でも登場するAWSサービスが利用されていたり、私の知識レベルを把握できるため、よろしければ一読ください。

AWS実践提案道場とは

まずは、本研修がどのようなものか説明いたします。
AWS実践提案道場とは、与えられた要件に対して満足できるAWSサービスを利用したアーキテクチャをグループワークで検討し、実際のお客様を想定して提案するトレーニングです。
もう少し分かりやすく理解するため、手順をフローチャートで表すと、

このようになるかと思います。
…難しそうですね。私はこういう実践形式のトレーニングは好きなのでやる気はかなりありましたが、要求を達成できる自信はあまりなかったです。
ただ、本研修の目標は正解を見つけることではなく、論理的な根拠をもって提案内容を説明することです。
つまり、AWSについて分からないなりに調べる力と考える力を身につけようということですね。

また、本研修のメリットとして、

• 各AWSサービスへの理解
• AWSサービスを利用したアーキテクチャへの理解
• 論理的思考力
• ディスカッション能力
• プレゼンテーション能力

などの向上が見込まれます。
まさにAWS初心者かつ社会人初心者である私にぴったりの研修ですね！

さて、では今回はどんな案件に対する提案を行うのでしょうか。
以下の画像をご覧ください。

なるほど。
動画配信サイトのインフラをクラウドに移行すると。
しかも、1年後にはユーザーが100倍の100万人に。
羨ましいことにかなり勢いのあるサービスのようですね。

ちなみに、画像には現在のオンプレでの構成が図で表されていますが、ヒントとしてこの構成に対応するAWSサービスを教えていただきました。

こんなヒントをいただいたなら、もうこの研修は終わったようなものですね。
勝ったなガハハ！

構成図とは

先ほどのフローチャートに、構成図という分かるような分からないような単語が出てきましたね。
ここでは、AWSにおける構成図の説明をいたします。

構成図とは、各AWSサービスの関連性をアイコン同士を接続させて表した図です。
百聞は一見に如かずということで、実例をご覧ください。

出典：【ハンズオン】AWSで実用的なWordPressを構築してみる！

この図は前回の記事でさりげなく載せられていたものと同じ図ですね。
EC2やRDSといったAWSサービスのアイコンが矢印で接続されている様子が分かるかと思います。
また、これらのサービスがどのリージョンやVPCに属しているのかということも、この図から読み取ることが可能です。

構成図を描くポイントは、構成図を見てもらう人に何を理解してもらいたいのかを意識することです。
細かいところまでサービスを列挙してしまうと、図がごちゃごちゃして見づらいですし、自分の提案のどこが優れているのか理解してもらいづらくなってしまいます。
お客様に提案を採用してもらうためには、何かしらの優位点を示さないといけませんからね。

この辺りのアドバイスはAWS公式でも参照できますので、ご参考にどうぞ！
参考：AWSのアーキテクチャ図を描きたい!でもどうすれば良いの?

私の提案

では、いよいよ取り組んでいきましょう！
ただ、私たちの作業を全て書き並べると日が暮れてしまうため、ここでは最終的な構成図のみご紹介します。
念のため申し上げますと、本構成図はAWS初心者たちが数日で考えたものであり、問題点が多々あることをご留意ください。

私たちはこのような構成図を提案しました。
簡単に本提案のポイントである、

• サーバーレス構成
• 高速・安定な通信
• セキュリティ強化

について触れていきましょう。

サーバーレス構成

本提案ではLambdaやDynamoDBといったサービスが採用されていますが、これらは全てサーバーレスという特徴を持ちます。
サーバーレスの一番のメリットは、運用工数を大きく削減できることです。

出典：AWS 責任共有モデルを GxP ソリューションに適用する | Amazon Web Services ブログ

AWSには責任共有モデルという概念があり、AWSサービスを利用する際に発生する責任の一部をAWS側が、他の一部を利用者側が負担します。
この負担の割合がサーバーレスのサービスでは非常に少なくなります。
例えば、EC2を利用する場合は可用性の確保やOSの管理を利用者が行わなければなりませんが、Lambdaを利用する場合はそれらを考慮する必要がありません。

本要件ではユーザー数が急増する見込みですし、競合サイトに先んじるためにもサイトの改修を行うこともあるでしょう。
その際に本来運用に回すべきリソースを開発へ回すことで、迅速かつ良質な改修が期待されます。

高速・安定な通信

皆さんは動画配信サイトの読み込みが始まってから何秒くらい動画の再生を待てますか？

私は5~10秒くらいでサイトをリロードするか視聴を諦めます。
皆さんも大体そのくらいなのではないでしょうか？
このように動画配信サイトには高速な通信が求められます。

あとは、いざ動画が再生されても何度も中断されたら嫌ですよね。いわゆる動作が重いという状況ですね。
つまり、通信は安定に行われなければなりません。

こうした高速で安定した通信を実現するためのAWSサービスがCloudFrontです。
CloudFrontはCDN（Content Delivery Network）と呼ばれる技術を利用することで、サーバーに対する負荷を抑制しつつユーザーへ低レイテンシでコンテンツを配信することができます。

また、S3と組み合わせることで静的サイトを作成することもできます。
構成図左下を参照していただくと、本提案でもこの組み合わせを利用していることが分かりますね。

セキュリティ強化

本提案ではセキュリティを考慮して、WAF・Shield・ACM・CloudTrailを採用しています。

元のオンプレ環境ではWAFに相当するファイアウォールのみ利用していました。
ユーザー数1万人の現時点ではそれでも良いかもしれませんが、100万人のユーザーを想定するのであればファイアウォールのみでは少々不安ではないでしょうか…

要件にセキュリティ強化は含まれていませんが、AWSにはWell-Architectedというベストプラクティスがあり、セキュリティ対策を推奨しています。
今回の仮想お客様にも、クラウド移行を契機にセキュリティ強化の検討をしていただきましょう。

所感

以上のような構成図作成・提案発表を約1週間で行いました。
ここでは説明と結論だけしか書いていないため、読者の皆さんには想像できないかもしれませんが、実に濃い1週間でしたね…
では、ここからは感想や反省点を述べていきましょう。

アーキテクチャを考えるのは大変！でも…

大変だった！

この一言に尽きます。
要件を確認してから提案発表までの期間を4日間いただきましたが、期限ギリギリに何とか形になったという状況でした。

これは、各AWSサービスへの理解が浅いことが問題でした。
何らかの機能を実現できるサービスが複数あると、その差異を把握した上で取捨選択をする必要があり、その調査と議論に多くの時間を割きました。
例えば、Webサーバーの働きを果たすサービスとしてEC2とLambdaがあります。
両者の差異の1つにサーバーレスかどうかということが挙げられますが、どちらを採用してもメリット・デメリット共にあるということで、大変議論が白熱しました。

ただ、こういった調査や議論を通してAWSサービスへの理解を非常に深めることができましたし、ディスカッションの方法についても課題を見つけることができました。
何より手探りで正解を模索していくという工程自体が非常に面白かったですね！

ディスカッションは難しい

「会議は踊る、されど進まず」という言葉を嫌でも思い出させられました…
と言いますのも、

• 進行役がいない
• 時間管理をしていない
• 知識・論点の共有ができていない

といった問題点により、グダグダな話し合いが続いてしまいました。
私個人としても、

• 自分の意見の主張ばかりしてしまう
• 曖昧な話題提起をしてしまう（〇〇の件どうしますか？ など）

といった課題が見つかりました。

そのため、最終的にはサービス毎に各々が調査して発表・質疑応答を行うという役割分担方式に落ち着きました。
その場しのぎとしては何とかなりましたが、これではチームの意味が薄いですね。

「ぼくのかんがえたさいきょうのこうせいず」になってない？

研修前の説明やフィードバックの際に何度も念押しされたことですが、提案はお客様第一で行わなければならないという大前提があります。
つまり、提案は自己満足で行われるものではなく、お客様が満足するようなものにしなければならないということです。

例えば、今回私たちはサーバーレス構成を提案しました。
確かにサーバーレスには運用コストが低いというメリットはありますが、一方でクラウド移行の手間が大きいというデメリットがあります。
本案件では、ユーザー数は現在1万人で1年後には100万人という想定がされていますが、本当にそうなるでしょうか。
何らかの原因によりユーザーが想定通り増えず、クラウドから撤退するという事態も十分に考えられます。
そのような事態を考慮するのであれば、移行の手間がかかるサーバーレス構成は決して最適だとは言えません。

他にも、セキュリティ対策はそんなに強化するべきなのか、日本国内のサービスであるのにCloudFrontを採用するべきなのかといった疑問点があります。
もちろん私たちなりにそれらの疑問点に対する回答はありましたが、それがお客様第一の回答かというと怪しい部分があります。

今回は実際にお客様が存在するわけではないため正解は分かりませんが、提案する際の姿勢は見失わないようにしなければなりませんね。

まとめ

今回の研修紹介は以上になります！
所感では反省点ばかり書いてしまったような気がしますが、学んだことや改善すべきことが多く見つかったため、個人的には非常に有意義な研修だったと感じています。
皆さんにとっても興味深い内容だと感じていただけましたら幸いです。

さて、次回も同様に研修紹介を行っていきたいと思います。
前回の記事を読んでくださった方は感じていることかもしれませんが、研修のレベルがどんどん上がっていて、不安を感じる一方でワクワクせざるを得ませんね！
次はどのような研修なのでしょうか、お楽しみに。
ここまで読んでいただきありがとうございました！