垣見です。
2024年9月6日、JAWS-UG千葉支部の第3回「AWS BuilderCards体験会」に参加してきました。このイベントはオフラインでの開催で、AWS BuilderCardsの遊び方について、参加者と一緒に実際に遊びながら学べる体験型のイベントです。
JAWS-UG千葉支部 #38(オフライン開催) 第3回「AWS BuilderCards体験会」 - connpass
今回のブログでは、その体験を振り返りつつ、感じたことや学びをレポートし、さらに、後日勉強のために復習したやり方を記述します。
※イベント運営の方やブログ内で紹介した方からはブログ公開許可を取得しています。ありがとうございます。
- このブログについて
- 参加時のスキル
- BuilderCardsとは?
- 体験会の概要
- 体験会の流れ
- BuilderCardsの魅力
- 学び:実際のアーキテクチャとゲーム上のポイントは違う
- 学びを深めてみよう
- 初心者も参加できる?
- こういう遊び方で練習できる
- おわりに
このブログについて
このブログは以下の方に特に参考になるように想定して書いています。
- BuilderCards体験会への参加を考えている方
- BuilderCardsの難易度、特に初心者も参加してよいかを知りたい方
- BuilderCardsによってAWSを学ぶ具体的なプロセスを知りたい方
- JAWS-UGのオフラインイベントの雰囲気に興味がある方
参加時のスキル
- 自分は未経験で入社した23年新卒採用エンジニアで、社会人歴としては現在2年目・実務としては半年ほどの経験がある
- 普段の業務ではAWSの検証や初期構築作業をしたり、お客様環境のコストや使用状況の分析・提案をしたりしている
- AWS認定資格としては Cloud Practitioner, SAA, SOA, DVA, SA Pro資格を保有している
- このようなJAUS(Japan AWSのUser Group)の開催するオフラインイベントに参加するのは初めて
とまあこんな感じで、AWSについて勉強はしていたものの、実際の現場で使われるワークロード・アーキテクチャに接する機会は少ないといった具合でした。
申し込んだ時点で既に「自分が申し込んだら定員に到達」という状況だったため知り合いを誘うこともできず、自分の知識がどの程度通用するのか緊張していました。
BuilderCardsとは?
BuilderCardsは、AWSの各種サービスをカード形式で学べる非売品のツールです。普段はドキュメントやコンソールでしか触れることのないサービスを、ゲーム感覚で楽しく学べるのが特徴です。
最初に配られるオンプレカードの手札から「EC2カード」や「VPCカード」など、サービスごとのカードを増やしたり入れ替えたりし、組み合わせたアーキテクチャを作って高得点(Well-Architected Pointの獲得)を目指すゲームとなります。
詳しいルールについてはこちらの公式の記述がわかりやすいのでご覧ください。
aws.amazon.com
実際にSWXで遊んでみた動画はこちらです
blog.serverworks.co.jp
非売品のカードについてはこういったイベントでしか配付されないため、それなりにレアアイテムです。本家は英語ですが、有志で日本語訳したカードもあります。日本語バージョンはまた手に入る場所が変わってきます。
今回使用したのはワークロードに特化したサービスのカードでしたが、他にもセキュリティに特化したカードもあるらしいです!
主催者の方によると、これからもどんどん進化するとかなんとか…目が離せないですね!
体験会の概要
JAWS-UG千葉支部 #38(オフライン開催) 第3回「AWS BuilderCards体験会」 - connpass
この「AWS BuilderCards体験会」では、参加者同士がチームを組んでBuilderCardsを遊びました。
参加者は約40名、運営スタッフを含めると50名ほどの規模で、4人1組でのチーム編成でした。
申し込み時には運営側とは別に「経験者・サポート枠」としての募集が存在するので、遊び方を知っている場合はこちらの枠がねらい目かもしれません。
BuildersCardsをやるのは初めての方も多かったようですが、和やかな雰囲気でした。
今回のイベントでは非売品のカード配付があったため、同じチームにはそれを目当てに参加した方もいました。
その方は募集サイトconnpassでイベント通知が来るように設定し、イベント募集が始まってすぐに申し込んだそうです。かく言う私もそれがイベント参加の1つの目的でした。
やはり人気イベントなようで、1週間ほど前には40名の定員が満員になっていました。
ただし参加直前に募集サイトを見たところ、2名ほどの空きが発生していました。平日夜の実施だったため、恐らく仕事などの関係でキャンセルする人がいたものと思われます。
満員でもどうしても参加したい方は、諦めず予定だけ空けておいてサイトをこまめにチェックするといいかもしれません。
私のチームは、AWS12冠のベテランエンジニア(すごい!)、今日AWSの勉強を始めたばかりという社会人1年目の方(すごい!returns)、そして私と、もう一人の女性エンジニアという構成でした。AWSベンダーさんも、事業会社の方も、AWSに関わる(関わろうとする)人は誰でもいらっしゃるようです。
体験会の流れ
事前にconnpassで予約をして、当日を待ちました。予約をするとconnpassのhome画面に予約が表示されるようになり、メールも届きます。
金曜日夜の19:00 〜 21:30のイベントで、18:30から開催場所のスポンサーさん(株式会社エス・エム・エス 様)のオフィスが開きました。
オフィスではconnpass画面に表示される申し込みQRを表示する必要があるので、用意しておくとスムーズに入れるかと思います。
予想に反し、1人で来ている人が多かったです。男女比率は6:4くらいで、女性が多くて安心したのを覚えています。
(おそらく)4人ほどのグループできている人もいらっしゃいました。
会場に入ると、4人グループに分けられた席に好きなように座っていくことになります。私を含めたみんなシャイで、人がいないテーブルに負荷分散していくので、グループで一緒になりたい人は早めに行くといいかもしれません。
また、時間になってからはすぐにゲームが始まってアイスブレイク・自己紹介を行うタイミングが少ないので、この待ち時間の間にある程度話をしておくとよりイベントを楽しめそうです。
AWS経験年数、普段触っているAWS、BuilderCardsの経験/ルール知識の有無、AWS構成経験(アーキテクチャに詳しいか)、参加した理由…あたりを聞くとゲームをするときのお互いの共通認識も持てるかと思います。
体験会の最初の部分で参加にあたっての注意事項の説明があり、その後運営スタッフからの説明を受けながら、各チームでBuilderCardsを使ったゲームに取り組みました。
2回ほどゲームに取り組み、10分ほど時間が余ったのでカードを見ながら振り返りを行い、最後にアンケートを答えて解散となります。
BuilderCardsの魅力
自分が感じた魅力は、「カードがかわいい」という点と、「勉強になる」という点です。
BuilderCardsは山札から新規にカードをめくって場のカードを更新していく形で取れるカードが増えていきます。(「マーケットプレイスでの更新と購入」という概念だそうで笑いました)
そのため、ひっくり返した瞬間になじみ深いサービスがあると、「S3だー!」「ここにきてのEC2!!!」のように、非常に盛り上がりました。自分の関わってきたサービスは取りたくなります。
まるで「文字だけで親しんでいた小説のキービジュアルが公開された」みたいな感覚です。カードが可愛すぎる。
そして体験会での最大の収穫は、単なる知識のインプットだけではなく、それを実際に使うシチュエーションに合わせて適切な構成を考える力が鍛えられることです。
次の章では具体的にゲーム中に学びになったポイントと、それに対して自分がどう学びを深めたかをお話します。
学び:実際のアーキテクチャとゲーム上のポイントは違う
体験会の中で、私はS3、EKS、API Gateway、OpenSearchというサービスを組み合わせたアーキテクチャでポイントを取得しようとしました。
この組み合わせはカードゲームのルール上ではアーキテクチャとしてポイントを得るために使用できるため、意気揚々と出した私。
サッ!
しかし、たまたま横で見ていた運営の方から「このアーキテクチャは成立してないかもね…」「これだったらVPC(Virtual Private Cloud)がないとEKSやOpenSearchがネットワーク的に機能しない」「API Gatewayは使わないかな」などなど、指摘を受けました。
どうやら、この構成は実際のAWS環境でそのまま実現することは難しいようです。
後から気になって調べたところ、API Gatewayは通常、Lambdaやサーバーレスアプリケーションとの連携で使われることが多く、EKSとの直接的な組み合わせは一般的ではないみたいですね。コンテナに全然詳しくないことがばれてしまいました。
なんとなく「サーバレスならAPI Gateway」「EC2以外のオレンジ色リソース(コンテナやLambdaやFargate)=すべてサーバレスだよね(※違う)」のように考えていた私にとって、この指摘は学び直しのきっかけとなりました。(そもそもEKS(not Fargate)はサーバレスじゃないんですね。ふわっとした理解で混同していたので反省です)
学びを深めてみよう
では、どのような構成ならば現実的なのでしょうか?
Well-Architectedなより良い構成を作るためには、遊んで終わりではなく「ゲーム内の偶然で引かれたカードに対してどれだけ学びを深められるか」という点が大事だと思います。
ここでは、反省としてEKS、OpenSearchが軸として使われる組み合わせを考えてみましょう。
EKS+OpenSearchの例
アーキテクチャの方向性を調べるために「EKS OpenSearch」で検索したところ、以下のドキュメントが見つかりました。
やっぱり信じるべきはドキュメントですね。
Amazon Elastic Kubernetes Service (Amazon EKS) クラスターの場合、OpenSearch を使用した集中ログ記録により、ログエージェント(Fluent Bit 1.9) を DaemonSet または Sidecar として デプロイするためのオールインワン構成ファイルが生成されます 。ログエージェントがデプロイされると、ソリューションはポッドログの収集を開始します。Amazon EKS cluster - Centralized Logging with OpenSearch
OpenSearchを使い、Amazon EKS クラスター上で動くアプリケーションのログを取り込むログパイプラインを作成できるようです。
ログデータのバッファレイヤー(※ログエージェントと OpenSearch クラスター間のに入り、ログ分析エンジンが過負荷にならないように保護する方法)としては、S3またはKinesis Data Streamsを使うことが出来ます。これは入れるかどうかは任意みたいです。
ふむふむ、これでEKS(⇒S3/Kinesis Data Streams)⇒OpenSearch、の様な流れがわかりますね。
- EKS
- OpenSearch
- S3 / Kinesis Data Streams(任意)
OpenSearch周りについては自分が検証したので今回は割愛しますが、必要であれば公式ドキュメントを見たり、実際にAWSリソースをさわってみたり、色々な企業のブログを読んだり、画像検索でいろんな構成図を見てみる様にしています。ブログや画像検索の場合、ソースの信頼性が分からないので、ヒントを得たと認識して再度公式ドキュメントを見直してみましょう。
VPC有無の確認
次に、会場で指摘された反省を生かし、EKS、OpenSearchでVPCが必須なものがないかどうかを確認してみましょう。ちなみにS3はグローバルサービスで、Kinesis DatastreamsはVPCとつなぐことが出来るもののVPCサービスではないようです。
OpenSearchはVPC内でも建てられますが、パブリックアクセスにすることも可能なようです。推奨がどちらかはともかく、VPCあるなしどちらでも選べるということですね。
また、EKSの公式ドキュメントを見てみると、以下の記述があります。
クラスターを作成するときは、異なるアベイラビリティーゾーンにあるVPCと少なくとも 2 つのサブネットを指定します。
ということで、基本的にコンテナはVPC内部で動かす必要があるようです。つまり、VPCカードが必要になりますね。
- EKS
- OpenSearch
- S3 / Kinesis Data Streams(任意)
- VPC
余談ですが、ECS・EKSのコンテナカードとは別に、EC2・Fargateカードも存在します。これってコンテナカードは単独では使えないのかという部分がとても気になっているのですが、この点どうなのでしょうか...。わかる方いたら教えてください。
(OpenSearchも裏でEC2が立っているけど無視しているし、単独で使っていいかと思っています)
ひとまず今回は、EKSカードだけで後ろのサーバーも含んでいるという考え方でいきます。
閑話休題...
この時点で、もう残りのカード枠は1枚ですね。
「AWS上の検証」として言い張るならこのままでもアーキテクチャとして成立し、提出出来るかと思いますが、せっかくなのでワークロードとしてもう少し考えてみましょう。
アプリ側をインターネットに繋ぐ場合
例えば、「EKSで動いているアプリケーション」にも説得力を持たせる必要がありそうです。
EKS上で動いているアプリが例えばウェブアプリケーションなら、ユーザーはインターネットからアクセスしてきます。
調べていくと、こんな表記が見つかりました。
AWS ロードバランサー コントローラーは、Kubernetes クラスターの AWS Elastic Load Balancer を管理します。コントローラーを使用して、クラスター アプリをインターネットに公開できます。コントローラーは、クラスターのサービスまたは Ingress リソースを指す AWS ロードバランサーをプロビジョニングします。つまり、コントローラーは、クラスター内の複数のポッドを指す単一の IP アドレスまたは DNS 名を作成します。Route internet traffic with AWS Load Balancer Controller - Amazon EKS
どうも、インターネットに公開するにはELBが必要みたいです。
EKSはそもそもコンテナ周りを良しなにやってくれるサービスなのですが、その一環で複数ポッドのロードバランシングとDNS・IPアドレス周りをごにょごにょやっていただけるコントローラーを作ることが出来るようです。コマンドでAWS Load Balancer Controllerをインストールしておくことで負荷分散を実行できます。すごいですね。
したがって、現実的なアーキテクチャとしては以下のような構成になったんじゃないでしょうか?
- EKS
- OpenSearch
- S3 / Kinesis Data Streams(任意)
- VPC
- ELB
(左下のIAMやTrail、CloudWatchはおまけです。カードは5枚までですが、ALBを省略する場合こちらの万能カードたちも付けられます)
社内有識者に尋ねたところ、おおむね良さそうだと判断いただきました。さらにありがたいことに、ロギング周りの勉強になるリンクも教えていただきました。
なお、Sidecar や Ingress というのは k8s において重要なコンポーネントになりますので関連情報を紹介しておきます。
Sidecar https://kubernetes.io/ja/docs/concepts/cluster-administration/logging/ Ingress https://kubernetes.io/ja/docs/concepts/services-networking/ingress/
「EKS」と構成図内でまとめてしまっている部分は、このような設定を使ってログ取得ができるのですね。そのログをS3に送ってOpenSearchとつなげればよいという訳です。
こんな感じで、偶然のカード運からとてもたくさんのことが学べました!
今回はここまでとしますが、実際に構築するところまでできるとさらに良いと思います。
初心者も参加できる?
できます。ただし、参加メンバーにはAWSがわかる人がいた方が良いというのが私の意見です。
まず、AWSを全く知らない場合、BuilderCardsに書かれた効果だけでゲームを進行することになります。例えば私がEKS、API Gateway、OpenSearchというサービスを組み合わせたアーキテクチャを提出してポイントを取得しようとしたみたいな感じですね。この組み合わせはカードに書かれたテキスト上ではアーキテクチャとしてポイントを得られますが、実際にはこのアーキテクチャは成立していません。
もし本当の初心者が参加する場合は、「実際には成立しなくてもOKにする」みたいなハンデをつけると良いかなと思いました。
逆に、経験者や学習を始めた人は、成立していなかったらどんどん指摘してしまった方が勉強になります。成立していないと言われた側は頑張って論理を組み立ててみてください。
初心者が参加するメリットとしては、生きた知識としてAWSリソースに親しみを持てて、結果的に勉強になることです。
最初に勉強するとき、「EC2」「S3」「IAM」…と、膨大な量の知らない単語に圧倒されてしまって敷居が高くなると思います。ですが、ゲーム内で出た単語として脳に入れておくだけで、事前知識が入るのではないかと思います。
さらに、BuilderCardsにはカードにサービス同士の関係性や使用シーンが書かれており、初めてAWSに触れる方でもカードに書かれた効果を読むだけで、「このカードはこういうカードと組み合わせられるのか」とわかるようになっています。
例えばこのS3カードを見てください。
私たちのチームは幸運なことに、全くの初学者の方と12冠のベテランの方が混在している珍しいチームでした。初めてAWSに触れて「全然わかりません...」と言った方に対して、わかる方が説明してくれる場面が見られました。自分も説明できる場所が無いかを考えることで、一緒に参加する人にとっても改めて学びになるなと思った次第です。
こういう遊び方で練習できる
体験会の時間が少しだけ余ったので、私たちのチームでは、カードを3~4枚引いて、そのサービスが何かを初学者の方に説明しつつ、使ったアーキテクチャを考えるという即興のゲーム(?)を行いました。
3枚引いて、それでできそうな構成図を机の上に作り、さらに「これがあれば成り立つのに…」というカードはどんどんつけ足していくというやり方です。
通常ルールが個人で戦略的にカードを集めるのに対し、こちらは完全ランダムでみんなで考える形ですね。難易度は通常ルールよりもかなり下がります。通常ルールが難しいと感じた方は、こうやって練習するのもいいのではないでしょうか?
これが思いのほか盛り上がり、自分たちでAWSのシステム構成を想像しながら、どのサービスをどう組み合わせれば良いかを議論する良い機会になりました。
おわりに
以上、JAWS-UG千葉支部「AWS BuilderCards体験会」に参加した体験レポートでした。
すごくすごく楽しかったので、ぜひまたいろいろなイベントに参加したいです。
JAWS-UGの活動に興味がある方は、ぜひ「connpass」というアプリからイベント情報を検索してみてくださいね!
例えば「AWS」や「勉強会」で検索すると、JAWS-UG千葉支部以外にも、全国各地でさまざまなAWS関連のイベントが開催されています。もしどこかで皆様とお会い出来たら嬉しいです!
このブログが何かの手助けになれば幸いです。
会場スポンサーの株式会社エス・エム・エス 様、JAWS-UG千葉支部の皆様、楽しい機会をありがとうございました!