ServerlessDays Tokyo 2019 参加報告 - コンテスト編

ネットワークサービス部の松田です。 10/21-22 の 2 日間で開催された ServerlessDays Tokyo 2019 の初日に行われたコンテスト形式のワークショップに参加したので、その様子や自身の振り返りをご紹介します。

Workshop Day

ワークショップ会場は DMM.com さんの六本木オフィスで、4 つのセッションが用意されていました。一部写真を交えてご紹介します。

AWS公式セッション (AWS Presents, Battle against Massive Load using Your Super Sonic Lambda Function!)
-- AWS Lambda を使ったコンテストなのですが、「大量に投入されるイングレスロードを、いかに高速、かつ効率よく捌くかを参加者間で競うコンペティションスタイル」とのことで、なにやらとても AWS の気合を感じます。

Azure公式セッション (Microsoft Serverless App WorkShop)
-- Azure の様々なサービスを駆使したアプリケーション開発を体験できるセッション。コンテンツはレベルに応じて用意されていたようです。

コミュニティ主催セッション (S.P.E.C. - Serverless Performance Empowerment Challenge)
-- 2 つ目のコンテスト形式セッションですが、こちらはコミュニティが主催します。「Serverless アプリケーションのパフォーマンス向上を競う、何でもありのサーバレスエンジニアを決めるパフォーマンスチューニングバトル・ロワイアル！」とのことで、こちらも盛り上がりを期待させる謳い文句です。

夜間セッション (Knativeで作るDIY FaaS)
-- こちらは他の 3 セッションが終わったあとの夜間開催だったため、写真がないのはご容赦ください。 レクチャーを交えながら Knative ベースのプロダクトを DIY するという内容です。最新テクノロジーを学習できる上に、他のセッションと合わせて 2 つ参加できるのは魅力的ですが、その分早くに満員となっていたため受講できませんでした。

これら 4 つの魅力的なセッションの中で私は S.P.E.C. (Serverless Performance Empowerment Contest) に参加しました。 パフォーマンスチューニングと言われると敷居が高そうに思いましたが、 サーバーレスに特化したコンテストは他に聞いたことがない貴重な機会ですし、 Serverless Framework (サーバーレスに特化した、多くのパブリッククラウドに対して Infrastructure as Code を実現する OSS) でのデプロイを必須要件とするあたりが普段使いの自分にとてもマッチしていたので、思い切って参加することにしました。

S.P.E.C. の様子

コンテスト当日、まずはその場で 2-3 人単位のチームが組まれました。 私は単独参加だったので初対面の人と 3 人チームを組みました。 メンバーの 1 人は去年のカンファレンスの登壇者でサーバーレスを実運用している人 (A さん)、 もう 1 人もサーバーインフラやアプリケーションの管理をしている Python 使いの人 (B さん) ということで、とても心強いメンバーでしたし、和やかな雰囲気で安心しました。 また、パフォーマンスチューニングという名前から出場者が集まりにくかったのか、全体のチーム数は 6 チームと比較的こじんまりとした規模でした。 しかし寂しい感じではなく、本当にコミュニティ型のコンテストという感じの、フラットで心理的な距離の近さを醸し出していました。 運営の方も同じスペースに参加者のように座って作業されていましたしね。笑

お題は開始直前に発表されるのですが、ペイメント系サービスを模したサーバーレスのアプリケーションでした。 それを全チームがそれぞれの AWS 環境にデプロイされると、コンテスト開始。 ベンチマーカーが一斉に稼働し始め、スコアが動き始めます。 しかし提供されるアプリケーションには、色々と罠が仕掛けられています。

• ロジックの不整合で正常に動かない部分がある
• パフォーマンスの低下要因が内在している

このため、放っておくとどんどん減点されていくのです！　一刻も早く止血してプラスの得点を獲得しないと…。 このようになかなかしびれる状況から約 7 時間のコンテストが始まりました。 （詳細レギュレーションはこちら）

コンテスト序盤は私のチームはいまいちうまく連携できず、順位を落とし続けて 5 位に。しかし途中から B さんがどんどんとロジックの不具合を改修していき、一時は 3 位まで上昇。 そこからは 3 人それぞれがパフォーマンス改善を試みて DB の構造改変やロジックのさらなる改善を進めていきます。

私は Lambda 内の API コールが同期的に行われて応答時間を悪化させていた部分に対して、非同期化してパフォーマンス向上するように試みました。 1 度やったことがあるパターンだったのでなんとか形になったのですが、どうも点数が上がらない。それどころか、細かい減点が増え始めている。

よくログをみると、リクエストに対する裏の処理を非同期化したため応答は高速化されたが、裏の処理（コールバックでクライアントに返す部分）でエラーが出ていたようでした。 しかしコンテスト時間内ではうまく改修することができず、おまけにクライマックスに向けてベンチマーカーが多重度を飛躍的に上げていくため、 積み重ねてきたポイントがどんどんと失われていくのをただ眺めることになってしまいました。

「ああ、すまない、これはもう、止められない…」
「いいんだよ、俺たちが果敢にトライした結果じゃないか…」
「Oh... 俺はお前らと一緒のチームになれて幸せだったよ」

そんな謎の一体感に包まれたまま（※若干脚色してます）コンテストは終わりを迎え、結果的に 6 チーム中 5 位でした。

振り返って

ここからは、コンテスト参加者としての出来を率直に振り返っていきます。 個人とチーム、2 つの切り口で見ていきます。

個人に関わる敗因と学び

• 場慣れ: どうも心と頭が浮足立った感じだった。文字通り肩に力が入った状態 (めちゃ凝った) で、本来のパフォーマンスが出なかった。その結果の凡ミスが命取りとなり、終盤の大量出血につながった
• コーディング力 (read/write とも) の不足: 身にしみるまで書いていない。落ち着いて調べればできるが、時間制限がある中ではいかに体が覚えているかが物を言う

こういった点は克服していくと、集中しにくい環境でもパフォーマンスを発揮できるようになり、日頃の仕事にも活きてくるものだと言えそうです。

チームに関わる敗因と学び

チームとしての段取り。これが何よりの敗因で、何よりの学びでした。

• 起きたこと:

  • お互いの得意不得意が見えない中、伺い合う感じでなかなか真っ直ぐにことが進まなかった
  • 結果的に何よりも大事な動作確認をスクリプト化するのが遅れたことで不具合の炙り出しに時間がかかり得点に影響した（結局 1 位チームも最速で不具合修正をしたことが勝因で、逃げ切りだった模様）
  • 他にも、ファイル分割せず GitHub を介して共同管理していたため、 commit 同士が conflict 、など

• やればよかった役割分担（例えば、の私案です。この手のコンテスト経験者の経験値をもらうべきだった）:

  • インフラ（AWS 環境整備, モニタリングやロギングの整備など）
  • デプロイとテスト
  • コード読み書き
  • 全体のマネジメント

このあたりの主担当を明確にし、ただしお互いにサポートし合うような形が良かったのではないかと思います。

開発スタイルも、コードをみんなバラバラに書くより、モブプロの形で 1 つのコードをみんなで確認しながら書いていけばよかったです。 精度も上がるしファイルの conflict も心配なし。 何よりチームとしてのパフォーマンスは一定化されるし、その間にお互いの能力が測れて、その後の分担がしやすくなるのではないかと思います。

それでも自信になった・良かった点

• 個人:
  • Serverless Framework でのデプロイや、アカウントやロギング・モニタリング環境の整備はスムーズで貢献できた
  • アーキテクチャの改善については対等以上に議論できた
  • SDK の使い方は多少アドバイスができた
• チーム:
  • 2 人は AWS 慣れしていてコンポーネントの選択肢を多く持っていた
  • 1 人は純粋にコードの理解・洞察力が強くて、本質的な課題を整理してくれた
  • 3 人ともフラットに話し合えるような人柄で、振り返ってみるととてもバランスの良いメンバーに恵まれた

振り返ると反省点ばかり目立ってしまいますが、自信になった部分も多いです。また、悔しさと引き換えにたくさんの学びがあったので、とてもポジティブな気持ちです。
あとは、何だかんだ言って終始コンテストを楽しめていたことが良かったです。業務では味わえないコンテストのゲーム性や、同じ技術に興味を持った仲間が増えた感覚にとてもワクワクしていました。

おわりに

コンテスト形式のイベントへの参加は勇気がいることもあります。しかし「はじめまして」の仲間と短時間でゼロから何かを形にすることで、普段の業務では得られない多くの貴重な経験ができます。 自分がちゃんと通用するところを確認できて自信になったり、強化していくべきポイントが明確になったり。 チームビルディングや、他のエンジニアの発想・習慣、デザインパターンやアプリケーション事例を学ぶこともできます。どう考えても本業にも活きてくるものばかりでした。

また、サーバーレス縛りのコンテストは他に見たことがなく、主催者の方が

「自分が解きたいから、まずは大会を作ることにした」

とおっしゃっていたのが印象深かったです。 とても感謝するのと同時に、自分もコミュニティに貢献していきたいと強く感じました。
ということでサーバーレスに限らずこういったコンテストはまだまだ参加したいですし、サーバーレスに関してはこういったイベントが増えるようにどんどんコミュニティに協力していきたいという熱い気持ちになったのでした。

みなさんもこういったイベントを活用して、ぜひサーバーレスアーキテクチャやそのテクノロジーに触れてみてください！