Go to Qiita Advent Calendar 2024 Top
LoginSignup
2
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

@k1nakayama(Keiichi Nakayama)inCloud Partner

AWS Serverless Tech Challengeで勝つ方法

Posted at

最初に

本記事はAWSやServerlessConf、またはその他所属する組織を含めいずれかの組織の見解や同意を得た内容でなく、あくまでも私個人の見解を述べたものであり、実際のところなんの責任も持てませんので予めご了承ください。

お前誰よ

上記のようなことを書くと何をもってこんな記事投げてるんだって思われるのが当然なので、簡単に私とServerless Tech Challengeの関わりをご説明します。

普段は業務でもAWSを使用した開発やAWSのパートナーとしてコンサルなども行っております。
ServerlessConf Tokyoは2016年からTokyoで始まったイベントですが、私は2017年から参加し
その2017年からワークショップにて始まったAWSのServerless Tech Challengeに2年連続で参加しました。

2017年は2人のチームで行い優勝することができました。
https://qiita.com/nakayama_cw/items/9140478202452bb8a299

そして今年も去年同様1人で申し込み現地で組まれた4人チームの一員として参加し、
今回も優勝することができました（今年は残念ながら単独優勝とはならず、同率一位がもう1チームありました）

このように2年連続で開催されたイベントでどちらも優勝をできたのは、私だけということもあり、
この経験を伝え、Serverlessをもっと多くの方に体験してもらいコミュニティーを活発にできたらと思いこの記事を書いてみることにしました。

AWS Serverless Tech Challengeとは

ServerlessConf Tokyo 2017 / 2018 の2年連続でWorkshop Dayに開催されたAWSによるWorkshopイベントです。

下記は2018年の内容ですが、正直2017年とほぼ同じ（テーマが少し追加されている程度）です。

概要

  • 現地で即席で決められた3～4人/チームで限られた時間内に成果物を作るワークショップ
  • 提示されたテーマからチームごとに１つ選び成果物を作成する
  • 各チームの発表をAWSのSAs(Solution Architect)が総合的に判断し優勝チームを選出する
  • 利用するプラットフォームはAWSのみ
  • 基本的にAWSサービスであれば何を使ってもよいが、本イベントは”ServerlessConf"です。（忖度してください）

スケジュール

10:15-17:00 実装
17:00-18:00 各チーム発表
18:00-18:30 審査＆結果発表

発表について

  • 各チーム5分
  • 発表には必ず下記の要素を含めること
    • 選択したテーマ
    • アーキテクチャ図
    • デモ
    • 一番工夫したポイント

表彰

  • SAsが独断でイケてると思ったチームを1チーム選出
  • 選出の観点は下記
    • アーキテクチャ
    • ライフサイクル管理（ロギング、モニタリング、CI/CD)
    • コスト
    • 耐障害性
  • 優勝チームには10万円分のAmazonギフト

提示されたテーマ

  • Chat
  • マッチングアプリ
  • SNS
  • Chat Bot
  • 自由

実装上のルール

  • 実装にあたり次の要素を必ず含めること
    • 認証機能（サインアップ/サインイン）
    • GUI（デザインは問いません）
    • 画像ファイルの取扱が可能（添付、共有など）

私のチームの内容について

2017年の内容はこちらを御覧ください

  • 選択したテーマ： Chat
  • チームメイト
    • 私
      • 普段の業務としては主に社内外の案件についてのソリューションアーキテクトとしての業務、バックエンドの実装、フロントエンドは実装もするが基本的には設計が主、プロジェクトマネジメントといった形でほぼフルスタックなエンジニア
      • CI/CDの構築、各リソースのCFnテンプレート作成・デプロイ、Athena/QuickSightの実装
    • チームメイトA
      • 普段は主にバックエンドが中心で、PHP/GOが得意
      • DynamoDB StreamsからJSONエクスポートのLambdaの実装と発表資料作成を担当
    • チームメイトB
      • AppSync,AWS Amplifyを使ったことがあり、Vue.jsやAngularも使えるフロントエンドもバックエンドもできる方
      • フロントエンドの実装を担当
    • チームメイトC
      • RailsやChatbotなどの経験あり
      • アップロードされた画像を圧縮、リサイズするLambdaの作成を担当
  • 発表

勝利のポイント

やっと本題です

開始15分で決めたいこと

  • 選択テーマ
    • これに時間を掛けるのは本当に無駄です。
    • 決めるポイントはチームメイト全員が一番自信をもって取り組めると思うもの。
    • 成果物に難易度は重要ではなく如何に重要な点を押さえつつ完成度の高いものができるかです。
  • 役割分担
    • まず1人1分以内で自己紹介
    • 大事なのはどういう経験が多く、自信をもって取り組める内容がなんであるかを簡潔に伝えること
    • 選択テーマとチームメイトの得意分野などに合わせて分担を行う
    • 役割としては下記を決める
      • フロントエンド担当（GUI担当）
      • バックエンド担当
      • CI/CDの構築担当（CloudFormationテンプレート等の実装）
      • 資料作成担当
  • 実装のスコープ（アーキテクチャ）
    • 今回の最終的な全体像について、BEST、MUSTの2段階程度はイメージを持つ
    • このとき実装上のルールを再確認しながらMUSTを考えること
    • タイムボックスを考える（MUSTまでの実装を15:00までにやろうなど）

アーキテクチャを考える上で留意する事項

  • 実際のテーマそのものの実装ばかりに目を向けない
    • 表彰で示されている通り、評価される観点にはライフサイクル管理やコスト、耐障害性が含まれます。
    • 基本的に多くのマネージドサービスはオートスケールしますが、中にはServerlessなビルディングブロックとして使われるものの、オートスケールを設定してあげなければスケールしにくいサービスもあります。（例：DynamoDB）
  • 最新のベストプラクティスに則って考える
    • AWS Well-Architected FrameworkやServerless Applications LensなどのAWSが公表する良いアーキテクチャに則って考える
      • 本来の使い方とは違う尖ったユースケースはこの場では使おうとしない
    • 出来れば直近1年間に発表された新サービス、新機能でより良く出来るなら使う（上記で書いたとおり、敢えて本来のユースケースと違う使い方をしてまで無理くり入れることはマイナスになり得るので注意）
      • 2017年時点ではオーソドックスな構成として、API Gateway+Lambda+DynamoDBで作るのが一般的な流れだったが、2018年はAppSyncが使えるようになったのでよりシームレスな動きを実装できるため、AppSync+DynamoDBで実装する。。。（などなど）
  • マネージドサービスのみで構成する
    • EC2等のマネージドでないサービスは使わない（ServerlessConfなので）
    • SaaS等のAWS以外のサービスは使わない（認証にAuth0を使うのではなくCognitoでしょ）

開発の進め方

  1. バックエンド担当はまず仮で各サービスの必要な設定を行っていく（Cognitoの設定やDynamoDBのテーブル作成など）
  2. フロントエンド担当は最低限必要なログイン/ログアウトなどのUIから作成を始める
  3. CI/CD担当はバックエンド担当が作っていっている設定をもとに、CFnテンプレートなどを作成しデプロイを行える状態を作っていく（CodeStarやCodePipeline等を使ってCI/CDパイプラインも忘れずに作成すること）
  4. 資料担当は上記と兼務するケースが多いと思うので、出来れば開発が止まらない範囲である程度進めたあとは出来るだけ早い段階で資料を作成する
  5. １つ１つ小さな単位で実装を進めていき、まずはMUSTな状態に近づけていく
  6. MUSTができた時点で残り時間を確認し、残り時間で確実に実装できる機能を選択し追加していく

機能としては最小限で良いですが、最低限含めなければいけない機能は必ず盛り込み、それ以降は少しずつインクリメンタルに進めること

前日までの準備

  • 個人のAWSアカウントを作成（これ当然）
  • 昨年までと同じテーマが出た場合のイメージトレーニング
  • 最新のサービスなどのBlack Belt 資料を見ておく
  • Slackでワークスペースの作成（当日のチーム内の連絡手段用）
  • 当日使用するノートのAWS CLIやIDE等の準備（Cloud9を使うというのもありかと）
  • 前日は十分な睡眠を
  • 当日朝はしっかり朝食を（今年はランチとして会場で提供されていたドーナッツ1個か2個とコーヒー2杯でした。。。）
  • フルスタックに対応できるよう、苦手な部分を重点的に予習（ハンズオンなどをやるのも良いかと）

上記をポイントとする根拠

KPIを考える

AWSさんがServerlessConfにWorkshopを提供するために、例えば今年（2018年）は現場にSA7名が来てくれてました。ここまでして彼らが得たいものは何であるか

  • 正しい使い方の伝導
    • このワークショップに参加する方は少なくともサーバーレスに興味のあるエンジニアです。彼らに正しい各AWSサービスの使い方がどうであるかを実体験をしながら学んでもらうことで、業務に活かしてもらいたい
  • 新サービス、新機能のトライアル
    • 中々業務で新サービスや新機能を使うことに抵抗があったり、機会がなく、その良さを知らないまま時が流れることがあります。そういったものをこの機会に学んでいただき実践で使うトリガーにしたい
  • 人材開発
    • AWSのSA候補になりうる人材を見つける（正しいアーキテクティングが行える即戦力を見つける）

他にもいろいろありそうですが、おそらくこのあたりだと思います。
全てに共通していることは、それぞれのAWSサービスについて、正しい使い方や考え方を持っているかを見ていることです。

実際のSAとの話

2017年も2018年も優勝の決め手は「アーキテクチャデザイン」ということでした。
そして2018年はもう少し実装が出来ていたら単独優勝だったと思うとも言われました。
つまり適切なアーキテクチャで進め、最小限でも最低限必要な要素が実装できて動いていることが重要です。

AWSの文化

AWSには有名な2 pizza teamなどの文化がありますが、おそらくその一つだろうMVP（minimum viable product)があります。
何かしらのサービスを新たにリリースする際には、実際に動く（実用可能な）最小限の要素で構成された製品をリリースし、顧客のフィードバックから徐々に機能を追加していきます。

これと同様に限られた時間の中で、如何に最小限のものを正確に作り上げれるかを大事にしているだろう人たちが審査を行います。

最後に

いかがでしょうか？
こんなこと分かってるよ！と思われる方も多いかもしれませんが、実際にこれを実践してみようと思うと、なかなか難しいです。

この記事を読んでくださっている方には是非ともサーバーレスの良さを再確認いただき、来年同様のイベントがあれば、優勝をしてもらいたいなと思います。

2
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
2
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?