1クール続けるブログ

とりあえず1クール続けるエンジニアの備忘録

【AWS Re:Inventレポート】CON208-R1 - [REPEAT 1] Build your microservices application on AWS Fargate

Build your microservices application on AWS Fargate

Fargateの初心者向けセッションです。
選ぶときに興味のあるトピックであれば、レベル関係なく受けようと思っていたのが良くなかったです。このセッションが4日間で受けたWorkshopのどれよりも簡単で少し物足りない感じがありました。それと疲れが非常に溜まっており体力的に限界だったのもあり、全て終わらせて途中で抜けてきました。

導入

ECS、特にFargateを使う上でどんな利点があるかを説明してくれました。EC2インスタンスを意識する必要が無いとかそんなような説明だったと思います。後は、AWSのプロダクトなので、完全に他のAWSサービスと統合されていてそれが強みとも言っていました。
資料は下記リンクです。

ecsworkshop.com

業務で使っているのはawsコマンドですが、Workshopではecs-cliを利用しました。そういえばECS CLIのv2が出るってコンテナワークロードに出てきていたような…?
CloudFormationでクラスターとALB(+TargetGroup)を作成するところからスタートです。

完成したあとの構成は下記。 f:id:jrywm121:20191207015823p:plain

Workshopの流れ

まずFrontendのRailsのアプリからデプロイしていきます。docker-composeの構文に少し似てますよね。envsubstってなんだろ?って思ったんですが、テンプレートエンジンみたいで、環境変数を埋め込んでくれるようです。普通に使っていきたい。
通常CloudFormationで埋め込むパラメーター周りをecs-cli使うと、コマンド引数に持たせる感じになるようです。ファイルに持たせることも出来るんでしょうか?宣言的じゃないと使うのには躊躇があります。Fargateだと、aws-vpcモードがデフォルトだからか、vpcも指定が必要になってくるようです。自分が注目したのは、--private-dns-namespace--enable-service-discoveryです。

cd ~/environment/ecsdemo-frontend
envsubst < ecs-params.yml.template >ecs-params.yml

ecs-cli compose --project-name ecsdemo-frontend service up \
    --create-log-groups \
    --target-group-arn $target_group_arn \
    --private-dns-namespace service \
    --enable-service-discovery \
    --container-name ecsdemo-frontend \
    --container-port 3000 \
    --cluster-config container-demo \
    --vpc $vpc

ServiceDiscoveryがEnableです。確かECSはRoute53で実現されていたはずと思ってRoute53を見てみます。
Private Hosted Zoneが作成されて、それが--private-dns-namespaceの引数に渡されているものと対応しています。そして、それぞれのタスクがAレコードで入ってきていますね。DNSラウンドロビンで振り分けられる形になるわけです(おそらく…)。ヘルスチェックもRoute53から行われる形になりますね。

f:id:jrywm121:20191207015201p:plain

恐ろしいことにあとこの作業をただただ2回繰り返します。
最後にローカルでのテスト方法を行います。明快でタスク定義をdocker-compose.yamlにtranlateするコマンドがあるので、それを変換してdocker-composeを起動させるだけです。なんだか物足りない…。

感想

このWorkshopは出なくても良かったかも知れません。結局4日間でExpo行けていないので、もっと早めに切り上げてExpo行くなど柔軟に行動すべきでした。

【AWS Re:Inventレポート】DOP201-R2 - [REPEAT 2] DevOps essentials: Introductory workshop on CI/CD practices

DevOps essentials: Introductory workshop on CI/CD practices

米食べたい気持ちが最高潮に達してしまった3日目2つ目のワークショップです。 AWSのCodeシリーズを使ったWorkshopです。CodeBuild/CodeDeployは使ってみたほうがいいんだろうなとは昔から思っていたのですが、仕事に即活きるかとそうではないものだったため、ずっと手を出せずにいました。

Workshopの流れ

最初にDevOpsとは何かという説明から入りました。Shared Responsbilityのお話とかですね。実践するとどんな利益があるのか?頻度の高いDeliveryやReliabilityの向上に約立つなど基本的な内容が多かったように感じます。そこからCodeシリーズを使ってCI/CDはどのように実現できるかというざっくりとしてお話がありました。どのプロダクトがどのフェーズの役割を担っているか説明が終わった後に実際にWorkshopに入りました。

f:id:jrywm121:20191206034518p:plain

資料はGitHubにて既に公開されていました。

github.com

最終的には下記の図のようになります。

https://github.com/awslabs/aws-devops-essential/raw/master/img/CICD_DevOps_Demo.png

前提

一番最初に思わず「?」となってしまうことがありました。Prerequisitesとして、CodeCommitで構成するために必要な鍵を生成しろとあるんですが、Cloud9を使う場合には必要ありません。そして、その直後からCloud9を使います!はて?なぜ必要だったのかいまだに謎です。

起点はもちろんCodeCommitからになります。あまりガシガシとは使えていませんが、正直、GitHubやBitbucketにくらべ、物足りない印象は拭えませんでした。サンプルコードはJavaのようです。

CodeBuild

Codeシリーズで使用するRoleとS3バケットをCloudFormationで作成し、いざCodeBuildの登場です。
CodeBuildはProjectという単位でパイプライン群を分けていくようです。このプロジェクトでは、ソースとなるコードとアウトプットになるS3バケットが同じになるので、リポジトリと1対1で紐づくイメージを持っています。Jenkinsとかで言うところのパイプラインに相当すると認識です。また、実行する環境(Dockerイメージ)も共通となります。今回はJavaがインストールされたコンテナイメージを使用しています。
buildspec.yml というファイルを作成し、その中にビルド工程を宣言していくようです。実はJenkins以外のCI/CDをあまり使ったことが無いのですが、yamlで書くのはすごく今どきって感じがしますよね。GitHub ActionsやCircle CIがそうなので。
.artifact.filesで指定したものが最終的にzipに固めてS3にアップロードされます。

version: 0.1

phases:
  install:
    commands:
      - echo Nothing to do in the install phase...
  pre_build:
    commands:
      - echo Nothing to do in the pre_build phase...
  build:
    commands:
      - echo Build started on `date`
      - mvn install
  post_build:
    commands:
      - echo Build completed on `date`
artifacts:
  files:
    - target/javawebdemo.war
  discard-paths: no

CodeCommitの直下にあるbuildspec.yml を読み取るので、作成したファイルをgit pushして上げて、CLIからaws codebuild start-build --project-name devops-webapp-projectってな感じです。CloudWatch Eventをトリガーにすることも出来るようですね。マージとかを契機にするには、その辺を組み込まなきゃいけないのが若干手間に感じました。

CodeDeploy

EC2インスタンスVPCを作成するCloudFormationを展開させます。なおEC2のUserDataでCodeDeploy Agentがインストールされているそうです。
deployment-groupというのを作っていきます。Applicationという括りの中にあって、どうやら本番・検証などのステージごとに作るみたいです。今回はEC2のタグでフィルターを掛けてKey=Name,Value=DevWebApp01を1つのグループとしています。appspec.ymlというファイルでこちらは定義していきます。

version: 0.0
os: linux
files:
  - source: /target/javawebdemo.war
    destination: /tmp/codedeploy-deployment-staging-area/
  - source: /scripts/configure_http_port.xsl
    destination: /tmp/codedeploy-deployment-staging-area/
hooks:
  ApplicationStop:
    - location: scripts/stop_application
      timeout: 300
  BeforeInstall:
    - location: scripts/install_dependencies
      timeout: 300
  ApplicationStart:
    - location: scripts/write_codedeploy_config.sh
    - location: scripts/start_application
      timeout: 300
  ValidateService:
    - location: scripts/basic_health_check.sh

合わせてbuildspec.ymlを修正します。直でCodeDeployが指定できるのはいいですね。どっちもAWSがやっている強みが出てますね。

f:id:jrywm121:20191206120955p:plain

CodePipeline

はいやっとパイプラインで統合できます。
これはGUIで作成していきます。これは本当に要求されるまま一つ一つ設定していくだけでした。
その後は本番用にdeployment-groupを作成し、Manual Judgmentを組み込みました。

f:id:jrywm121:20191206122216p:plain

感想

CodeStarというのを使えばこれらが一発ででき出来上がるというので、そちらも試してみたくなりました。普通に使い勝手が良かったような印象はあります。EC2へのデプロイだったので、ECSやEKSで使いますか?と言われると首を捻ってしまうかもです。

【AWS Re:Inventレポート】AIM223-R4 - [NEW LAUNCH!] [REPEAT 4] AWS DeepComposer: Get started with generative AI

AWS DeepComposer: Get started with generative AI

火曜のKeynoteの後に見たら偶然予約できました。おそらく新セッションが出てくるタイミングでUnreservedされた座席があったのだと思います。Walk-Upの列はとんでもないことになっていました。

正直、機械学習についての知識が全くない状態ではWorkshopの後半は、shift+Enterを繰り返すだけのただの人形と成り果ててしまいます。自分は人形と化しました。 悲しいですね。

GANsに関する説明

機械学習は3つに分類されるというお話から始まりました。正直自分が知っていたのはこのレベルまでです。

その中でGANsはUnsupervised learningに分類されるものだそうです。
generatorとdiscriminatorという2つのネットワークを利用するそうな。generatorはその名のとおり、物を生み出す側で、DeepComposerでは音楽を生み出します。discriminatorはそれを評価してフィードバックすることで、よりクオリティを上げていくというものだそうです。説明の中では、オーケストラに例えていました。generatorは演奏者たち、そしてdiscriminatorは指揮者にあたるもののようです。素人でもどこか腑に落ちる(ような気持ちになる)説明でした。

軽く説明を受けた後に簡単な小テストが行われました。上位に入るとスピーカーがもらえたようです。テスト自体は結構簡単だったのですが、なにより速さが足りない。スピーカーをもらうことが出来ませんでした。

サンプルのモデルでGANsを体験してみる

AWSコンソールからDeepComposerのページに飛んでみます。アカウントを頂いたのですが、どうやらre:Invent最終日の24時まで有効なようです。SageMaker使う部分に関してはお金かかると思いますし、結構複雑なアーキテクチャ組んでたので太っ腹ですね!

DeepComposerをPCにつなげて、実際に弾き、それを録音することで音をインプットさせます。そのインプットした音を、モデルを用いてアレンジさせます。サンプルのモデルとして用意されていたのは、「Pop」「Rock」「Symphony」などの5種類です。
みなさん思い思いにDeepComposerを奏でて、モデルによってアレンジさせていました。

SageMakerを利用してモデルを作ってみる

恥ずかしながら、まったく分かりませんでした!

SageMakerからJupiterNotebookを起動させると、音楽生成GANsに関する基礎知識とそれに対応するPythonの構文がざーっと書かれていました。一応それぞれGoogle翻訳にかけて読みましたが、後半はわからない単語の応酬でなかなか厳しいものがありました。

かろうじてわかったのはモデルを生成する部分のAWSアーキテクチャのみでした。

f:id:jrywm121:20191206032558p:plain

DeepComposerは無事ゲットすることが出来ました!セッションを受けてると、SWAG行ったときに貰えるようです。めちゃめちゃ嬉しい。

【AWS Re:Inventレポート】HAC301-R1 - AWS GameDay: Main event countdown (PM)

AWS GameDay: Main event countdown (PM)

2日目の午後からは、GameDayに参加してきました。
午前中は何をしていたかというとAndy JessyのKeynoteを見てきました。プレゼンの合間に生バンドの演奏が挟まり、それぞれのトピックのトレンドを象徴するかのような曲が流れました。例えば、QueenDon't Stop me nowなど…。いろんな発表がありましたが、個人的に周囲含め一番盛り上がったのはEKS on Fargateでした。あとAWS Graviton第2世代のM6gインスタンスにはとても期待を持っています。

GameDayが始まる前に

アメリカに渡ってきてからの2日間で自分が思ったより英語の聞き取りが出来ないこと、言葉も全然思ったように出てこないことを認識していました。そのため、チームを組んだときに言語の壁で足を引っ張ってしまうのでは無いかと心配でした。もし、日本人4人で出れると有り難いなーなんて思っていたら、直前でなんとか組むことができました。自分はチームの他のメンバ全員と初対面でしたが、皆さん優しくて非常に助かりました。

GameDayで大変だったこと

内容とか書こうと思ったんですが、外部に垂れ流していいやつか分からなかったので、ぼやかします。 システムの構成が中途半端になっているので、その部分の補完を行い、来る高トラフィックに備えるというのが趣旨でした。サービスの1つはEKS上で構築されていたので、自分がそこを担当することになりました。EKSやっているのが活きて本当に良かったです。
単純にそれだけなら簡単なんですが、妨害が入ります。ネットワーク層での構成がゴリゴリ変えられて、普通にサービスダウンしました。そういった妨害が入ることが頭に無かったので(説明をちゃんと聞いてなかった)、「ぼくなんかやってしまった?やってしまったの?」とパニクりました。特に踏み台にアクセスできなくなり、NewRelicにもデータ飛ばなくなったときはパニック最高潮でした。
結果、指揮を取ってくれていた方が自分にヒントをくれたおかげで原因に気づくことができました。気持ちよかったです。

GameDayで得られたもの

普段触らないサービスに触れたのは良かったと思います。良かった反面、やはり使い慣れていないサービスを使うのはかなり難しそうで、チームの方の中の一人はその部分に注力してくださっていたのですが、ハマりポイントもあったようで本当に大変そうでした。

思い込みがいろんな問題の解決を遅くしてしまったように感じます。普段の障害調査もこういったふうに思い込みのせいで原因究明に行き詰まってしまっていたことがもしかしたらあったのかもと思いました。気づきを得られたのはとても良かったです。

あとニット帽を得ました。かわいいです。

結果

80ぐらいいるチームの中で22位でした。一時は1位だったときもあったので悔しいですが、後半一度かなり落ちたので盛り返せたほうかなと思っています。AWS Summitでやってほしいなと思う内容でした。

チームメンバの方とはJapan Nightでそのままお話出来たのでとても嬉しかったです。

f:id:jrywm121:20191205073028p:plain

【AWS Re:Inventレポート】CON209-R - [REPEAT] Using AWS App Mesh to monitor and control your first containerized app

Using AWS App Mesh to monitor and control your first containerized app

1日目としては3回目のWorkshopになります。Walk-Upで着いたのが30分前くらいだったのですが、すんなり入れました。Bellagioが会場だったのですが、セッションが少ない会場の一つだったためWalk-Upが増えにくいのかもしれません。賭けに出て良かった。
ちなみに列で待っていたときに、WeaveWorksのお兄さんらしき人がルービックキューブをくれました。 かわいい。

f:id:jrywm121:20191204223546p:plain

ざっくり言うとAppMesh導入したらどうなるの的な話でした。なんだか講師陣も優しく、声をかけてくれるしとても暖かかったように感じます。当たり前なんですがWorkshopでも会場や雰囲気によって温度感が全然違いますね。
あと、EKSのWorkshopのときにも思ったのですが、Workshopの会場はディスプレイ用意されていることが多いです。つなげるコード持ってくのがいいと思いました。自分はそもそもアメリカにも持ってきていないので断念しています。

Workshopの流れ

ECS, EKS, EC2 の順にそれぞれに対してAppMeshの導入を行いました。
実は最後にCloudMapも残っていたのですが、時間が余っているにも関わらず切られてしまいました。正直、CloudMapでサービスディスカバリしたかったです。自分でやるしか無いかと思ってはいますが、無料利用枠に入っているのか割と不安です。
EKSのときのWorkshopと同じでCloud9のセットアップから行っています。

資料はこちら

www.appmeshworkshop.com

ベースラインのスタック作成

AppMeshを導入する前+Kubernetesリソース作成する前の構成はCloudFormationで作成していきます。フロントエンドのRubyはEC2のAutoScalingGroupで、バックエンドのCrystalがFargateとEKSクラスターという構成でデプロイされます。ASGとFargateの前には当然ながらロードバランサもいます。
自分がやったときには既にスタックは作成されていて実際に作成というのは行われませんでした。

https://www.appmeshworkshop.com/images/app_mesh_architecture/AppMeshWorkshop.png

NodeJsサービスのデプロイ

既に存在するEKSクラスターに対して、nodejsのサービスをデプロイしていきます。DeploymentとServiceをapplyするだけの簡単なお仕事です。その後に、フロントエンドのサービスからアクセスできるように、Route53にServiceリソースの向き先の入ったレコードを追加します。
フロントエンドのサービスのELBにアクセスすると、下記のような画面が表示され、3つのサービスが構成されていることが確認できます。

f:id:jrywm121:20191204231206p:plain

Crystal(Fargate)のメッシュ化

メッシュの作成

まずaws create-meshコマンドでメッシュを作成します。名前はappmesh-workshopとしています。「サービスメッシュはその内部に存在するサービス間のトラフィックの論理境界」としかその後の説明にないんですが、あまりピンと来ません。このコマンドでやっているのは結局コントロールプレーンの作成なのではと勝手に思っています(どうなんでしょう?)。

Virtual Serviceの作成

Virtual ServiceはVirtual Nodeによって提供されるrealなサービスの抽象化とのこと。…分からないです。Virtual NodeはASGやAmazon ECS Service, Kubernetesのdeploymentなど、特定のタスクグループへの論理ポインタを指す。これは分かりやすい。serviceDiscoveryの設定やlogging、listener(healthcheck)などの設定ができることからも非常に分かりやすい。そのVirtual Nodeを作成した後に、対応するVirtual Serviceを作っていく。Virtual Serviceに設定するのはVirtual Nodeの名前とサービス名にあたるFQDN。 今回はサービス名としてcrystal.appmeshworkshop.hosted.localを指定したので、Virtual Serviceの作成によってappmeshworkshop.hosted.localというprivate hosted zoneが作成され、Aレコードとしてcrystal.appmeshworkshop.hosted.localが登録されます。

Envoy Proxyの作成

AWSのAppMesh統合ではiptableを書き換えることでコンテナへの通信をインターセプトしているそう。Crystalのポート3000に通信がきたら、代わりにEnvoyがリッスンする15000ポートに流します。処理した後はEnvoyからCrystalへ通信を転送します。そのためレスポンスもEnvoyを通すことになります。
タスク定義にサイドカーのEnvoyの定義を追加してあげるだけはなく、proxyConfigurationというものも構成します。ここでTYPE: APPMESHを指定することで、指定したcontainerNameのコンテナに通信をインターセプトして流す形になります。
フロントエンドRubyのEC2にsshしてcrystal.appmeshworkshop.hosted.localに対して通信を行うと、Fargateの手前のinternal ALBに対して通信されます。curl -vで確認するとEnvoyから通信されていることが確認できるという流れになるようです。

NodeJS(EKS)のメッシュ化

メッシュ自体は既にappmesh-workshopという名前で作成されていますので、Vitrtual Serviceの作成とEnvoy Proxyの作成という形になるかと思います。

HELMでApp Mesh用のパッケージ導入

AppMesh用のCRDをapplyしていきます。リソースは下記リンクです。その後にhelmでeks/appmesh-controllereks/appmesh-injectというパッケージをインストールします。後者はmutating admission webhookらしいので、おそらくマニフェスト登録したときに、勝手にEnvoy Proxyを注入してくれるやつです。

github.com

Virtual Serviceの作成

Virtual NodeもVirtual ServiceもCRDで先程定義されたので、マニフェストをapplyして作成完了です。Virtual Serviceはパスルーティングも可能なんですね。小出しにそういう情報を出してくれるあたりが憎いです。kubectl label namespace appmesh-workshop-ns appmesh.k8s.aws/sidecarInjectorWebhook=enabledでnamespaceにlabelingすると、admission webhookが有効になるようです。podをdeleteするとenvoyがある状態で上がってきます。フロントエンドRubysshすると、Virtual Serviceリソースの.metadata.nameに記載したFQDNでアクセスできます。

Ruby(EC2)のメッシュ化

ECSのときと同じようにawsコマンドでVirtual NodeとVirtual Serviceを作成します。SSM Agentを使用して、Envoy Proxyを注入することで作業は完了です。
SSM Agentに関する知識が無かったので、ここは脳死でコピペしていました。

Loggingの有効化

Container InsightとX-rayの有効化を行いました。ECSはタスク定義のログ定義とX-Rayサイドカーコンテナの注入、KubernetesはContainer InsightのデプロイとHelmでX-rayのパッケージをインストールすることで出来ました。

感想

AppMesh全然わからんという状態からちょっと分かる状態に持っていけるのは、Workshopのいいところですよね。CloudMapもやりたかった惜しい!

【AWS Re:Inventレポート】CON203-R1 - [REPEAT 1] Getting started with Kubernetes on AWS

Getting started with Kubernetes on AWS

去年のWorkshopの資料を見たことがあったので、行くか迷ったんですが、1年経ってアップデートがあるかも…?であったり復習としてはちょうど良いのではないかという気持ちで参加いたしました。
資料を見る限りでも135分では到底終わりそうにないボリュームが有ることが分かります。個人的にはHelmを飛ばして、Cluster AutoscalerやIAM Roleとの統合をやったほうがいいのではなんて思っていたりもしました。
資料はこちらです。con203というタグがセッション番号と紐付いているみたいです。

eksworkshop.com

Workshopの流れ

チームハッシュを入力して、Workshop専用のアカウントにログインし、Cloud9をセットアップするところまでは他のWorkshopと同じです。なぜかCloud9のテーマを変えるような指示があった点だけは違いますが…。ダークテーマのほうが見やすかったのは確かです。View -> Theme -> Solrized -> Darkで設定しました。
EKSに関してはCloud9から触れるように権限周りが対応出来ていないのか、追加の処理を行うことになります。まず一時認証情報をOFFにします。その後インスタンス一覧から見れるCloud9のインスタンスに、管理者権限のついたIAMRoleをアタッチします。最後に、Cloud9側の認証情報を消して、GetCallerIdentityで改めて認証情報の取得を行いました。

ここからの流れは実にシンプルで、ほとんどWorkshop資料のまま進んでいきました。

eksctl を使ったEKSクラスターの展開

この展開にかなり時間がかかってしまったため軽くKubernetesの説明や質問コーナーを設けていました 。 今になって面白いなと思うのは、参加者からEKS on Fargateはまだかという質問を受けたときに講師がちょっと待ってねと流して、GitHubに載っけているコンテナワークロードを紹介し始めたときです(さてはキーノートで出ること知ってての所業か)。

Kubernetes Dashboardのデプロイ

ここでダッシュボードにアクセスするためにkubectl proxyが使うのですが、実は使ったことがなく頭を捻りながらコマンド打ってました。既にこの時点で参加者間で進捗に大きな差が出来ており、あんまり説明などがされぬまま進んでいっていたように感じます。
kubectl proxylocalhostKubernetes API serverの間にProxy Server作るというもので、通信がKubernetes API Serverにフォワーディングされるものです。 実際にうったコマンドはkubectl proxy --port=8080 --address='0.0.0.0' --disable-filter=true & となるのですが、これはIP0.0.0.0のポート8080番の通信を行うと、リクエストにFilterをかけずに(XSRF脆弱性が生まれるらしいですが…)Kubernetes API Serverにフォワーディングされます。--disable-filter=trueに関しては実稼働環境に使うのは良くないが開発環境なら良いと注意書きがありました。

勉強不足でKubernetes APIを通してServiceにアクセス出来ることを知らなかったので、知れてよかったです。こちらのドキュメントに記載ありました(Access Services Running on Clusters - Kubernetes

Exampleアプリのデプロイ

基本はDeploymentとServiceリソースをapplyしていくだけの作業です。
冷静にサンプルアプリの1つのサービスにCrystal使われてるのびっくりでしたね(AWS社内では使われてたり…?)。
使用しているアカウント内で初めてELBを作る場合には、ELBに紐づくRoleが無いらしいので、作ってあげる必要があるようです。 aws iam get-role --role-name "AWSServiceRoleForElasticLoadBalancing" || aws iam create-service-linked-role --aws-service-name "elasticloadbalancing.amazonaws.com"というコマンドでした。
あとはscaleコマンド使ってpod増やしてみたりしました。

Helm

Helmのセットアップを行います。
nginxをHelm使ってデプロイしていきます。リポジトリの追加方法やパッケージの削除方法を学びます。 ExampleアプリをHelm使ってデプロイすることを通じて、Helmパッケージの作り方を学びます。

(自分は途中退出)

行きたい別のセッションがあったため、残りが40分ほどありましたが、退出しました。残りも基本的には知っている部分(ClusterAutoScalerやaws-auth, metrics-server)だったので一旦大丈夫でしょう。

他、気になったところで言うと、Managed WorkerNodeがこの前出たので、eksのコマンドがeksctl create cluster --managedのように--managedオプションが付くようになってました。ただ資料上、ClusterAutoscalingでノードグループの台数いじるところはまだASGのキャプチャだったので、対応出来ていない部分もあったのかもしれません。
当たり前ですが、Managed WorkerNode推奨って感じですね。

【AWS Re:Inventレポート】SVS201-R - [REPEAT] Build a serverless web app for a theme park

SVS201-R - [REPEAT] Build a serverless web app for a theme park

セッション会場(MGM)まで

初日の朝8時半に滞在先のTreasure Islandを出て、Mirageシャトルバス乗り場に向かいました。 Mirageシャトルバス乗り場は北口にあり、前日に行ったVenetianに比べ遥かにわかりやすかったこともあり、すんなり乗り場までたどり着けました。 シャトルバスも特に混むことなく、ゆったり過ごせた印象があります。

MGMに入った後に荷物検査を行うところがあるのですが、ゲート的なところを通るときにセンサーがあり、それに引っかからなければ荷物検査を受けることになるみたいです。なぜか自分は引っかかってしまい、荷物を見せる形になりました。
階段を上がると、DeepRacerの大きな会場が左手に見えます。自分はそこから右手に行く形となりました。レストラン街を進むとT字路が現れましたが、そこを左に行き、階段を下り右亭に行くと会場が見えました。そこでも荷物検査があったのですが、なぜか引っかかりませんでした(なぜ?)。

Walk-Up初挑戦

行こうと思っていたセッションはReserve出来ていなかったので、Walk-upで入ることにしました。ask meの方にどこがWalk-upの列かを聞き並びました。並ぶと前後の方とかで世間話があったんですが、自分の英語力の無さ故に入れず悔しい思いをしました。これはWorkshopの間続きます(悲しい)。

Workshopの内容

テーマパークのアプリを作成することになります。機能は下記です。

  • アトラクションを地図上に表示する
  • 待ち時間見積もりの更新を受け取り表示する
  • グリーンバックで撮った写真を加工し背景をテーマパーク風に加工する

使用したAWSサービスは下記でした

  • Cloud9
  • Amplify
  • Lambda
  • CodeCommit
  • DynamoDB
  • S3
  • CloudFormation(samを通して)

資料は既にパブリックになっています。

github.com

Workshopの流れ

イベント用のページURLが書かれている紙がテーブルに用意されているので、それを利用する。一緒に書かれているチームハッシュを入力すると、AWSコンソールに入れるようになる。
スピーカーの人がハンズオン用のURLを共有してくれるので、それを手で打って開始。
ほとんどリスニングでなくリーディングになるので、結構楽です。ただテーブルを囲む形で着席するので、会話が活発に起こっているテーブルもありました(自分のいたテーブルです)。

感想

自分が扱っているサービスはコンテナとそれに関わるサービスだけなので、S3以外は初めて触りました。
Lambdaのデプロイはコンソールからとsam-cli経由のものが経験できてよかったです。Cloud9はAWSに買収される前に使っていたので懐かしい気持ちになりました…(見た目の感じはだいぶ変わっていましたが)。

それぞれの連携のされ方は実際触ってみると勉強になりますね。 AmplifyとCodeCommitだと下記のような形です。
CodeCommitの中身(https://innovator-island.s3-us-west-2.amazonaws.com/front-end/theme-park-frontend.zip) -> Vue.jsを使ったPWA

  • CodeCommitでリポジトリを作成する
  • AmplifyのセットアップでCodeCommitのリポジトリ(+ブランチ)を指定する
  • CodeCommitのPushごとにAmplifyのデプロイが走る

f:id:jrywm121:20191203060809p:plain
Amplifyでデプロイされる様子

SAMで色々作っていたのもびっくりしました。DynamoDBからCognitoまで…本番運用されるときにここまでSAMに任して大丈夫なのかはちょっと分かりませんが…。
下記のリソースをデプロイしていました。

  • 2 Lambda functions and a Lambda Layer
  • 3 S3 buckets
  • A DynamoDBTable
  • A Cognito UserPool
  • An AWS IoT thing
  • Several IAM Roles and Policies.

使ったことないサービスを使って実際に動かせるのは得だなーと思いました。