GameWith Developer Blog

GameWith のエンジニア、デザイナーが技術について日々発信していきます。

GameWith の 手動テスト方法について #GameWith #TechWith

はじめに

こんにちは!GameWith QAエンジニアのIです!

今回のブログは GameWitfh で実施している QA について書いていきたいと思います。

QAとは

Quality Assurance の略で、プロダクトの品質を保証するための業務全般を行なっています。

企業やプロダクトによってチームがあったりなかったりその体制はまちまちですが、GameWith では開発部にQAエンジニアが所属しています。

自動テストと手動テストを併用していますが、今回は手動で行っているテストについて紹介していきたいと思います。

行なっている手動テスト

大きな開発や難易度が高いと思われるテストはQAエンジニアが実施します。

JSTQB(Japan Software Testing Qualifications Board)のテスト7原則でも言われている通り、 テストはやろうと思えば無限に行うことができ、また不具合が0であると証明することはできません。
参照:テスト7原則(Foundation Level シラバス 日本語版 Version 2018V3.1.J02より)
http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018V31.J02.pdf

当然リリースまでの期日も遵守しなければなりません。

その中でどのようなテストを行うのが効果的でよりリスクを下げられるのかテストの設計を行い、 それを元に実際のテストケースに落としていきます。

テストケースはExcelなどのスプレッドシートを用いて管理している場合も多いかと思いますが、 GameWithではGitHubのIssueにMarkdownのtasklist方式で記載を行い、チェックをつけています。

f:id:t_iwsk01:20201124163441p:plain
テストケースの例

この方法はプロダクトの仕様に理解があることが前提にはなりますが、 冗長な条件や手順の記載を避けることで、テスト観点(意図)が端的に伝わるテストケースに仕上げることができます。

結果的に開発担当エンジニアのレビューへの負担を軽減する効果も見込めます。
(別ドキュメントにしたり文章量が増えるとどうしても確認の工数が増え、結果的に目も行き届かなくなります)

テストが可能になり次第、あらかじめ策定した環境にてテストを実施するのですが、 ここでも経験をベースにテストケースの行間を読んだり、仕様の変更などに対して柔軟に対応していきます。

事前の準備は行いますが、全体的にはいわゆる経験ベースの探索的テストに近い部分もあります。

以下はJSTQBにおける探索的テストの定義です。
(JSTQB-Syllabus.Advanced_TA_Version2012.J01より)
http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018V31.J02.pdf

「探索的テストには、テスト担当者がプロダクトとその欠陥の学習、完了すべきテスト作業の計画、テストの設計と実行、および結果の報告を同時に行うという特徴がある。
 テスト担当者は、テスト実行時にテスト目標を動的に調整し、軽量のドキュメントのみを準備する」

こうしたフローを採用することで、1サイクルの短い開発にも素早く効率的にテストが行えるようにしています。

すべてのテストをQAエンジニアが行うわけではない

各プロジェクトの内容によっては、開発を担当したエンジニアに直接テストケースの作成や実施を行ってもらう場合もあります。

GitHubのPull Requestに、エンジニアが開発機能に対するテストケースを記載

QAエンジニアにメンションをつけてレビューを依頼(通知が飛ぶ)

QAエンジニアでレビューして足りない項目がないかを確認し、必要であればテストケースの加筆修正を行なってもらう
という流れです。

こうすることでエンジニアに「開発とテストはセットである」という意識を身につけてもらい、 品質への意識を高く保ってもらうという狙いがあります。

「テストや品質の責任はQAエンジニアのもの」という意識が根付いてしまうと不具合の作り込みも増え、 実際にプロダクトの品質が低下することに繋がってしまう恐れがあります。

使用するユーザーのことを想像したり、より良いプロダクトを提供しようという意識は大切なものです。

QAエンジニアはこういった品質に対する在り方の提案も行なっています。

おわりに

冒頭でQAは企業やプロダクトによってあったりなかったり、体制が異なると書きましたが、 所属する人や業務のフロー、使用しているツールなどにもよってもいろいろ条件が変わってくるため、「これが正解」と言った形は存在しません。

QAエンジニアは品質を担保することももちろん大切な業務ですが、 既存のやり方にとらわれず、プロダクト開発におけるQAの在り方をリードしていくことも大きな役割だと考えています。

今後もそのために尽力していきたいと思います!

GameWithのDeveloper向けTwitterアカウントも開設しています。
良かったらフォロー宜しくお願いします!

twitter.com

GameWithのリプレイスについて vol.3 ~俺たちは Shadow DOM で Micro Frontend の理想を追う~ #GameWith #TechWith

はじめに

こんにちは!Incremental Stream Team の @53able です!

GameWithのリプレイスについて第3回目の記事である今回は、 GDS(GameWith Design System) の根底にある方針や考え方について書いていきたいと思います。

前回の記事はこちらから御覧ください

tech.gamewith.co.jp

GDS が目指しているもの

GDS は前回のブログでも書いたように、下記のような世界を目指しています。

  • どんなプロジェクトでも簡単に利用できるHTMLコンポーネントの提供
  • 将来的にデザイナーも UI/UX 改善に利用できるようにしたい
  • 将来的にエコシステムを OSS として公開したい

どんなプロジェクトでも簡単に利用できるHTMLコンポーネントの提供

GDS では Web Components というWeb標準技術を利用して、HTMLコンポーネントを提供しています。

Web フロントエンド アプリケーションを開発する際に考えられるのは Vue や React や Angular などといったフレームワークがあげられます。

これらのフレームワークで開発を行った場合、例えば Vue を採用した際に、React のアプリケーションにコンポーネント提供した場合かなり困難であると考えられます。

そのため、Web 標準である Web Components のコンポーネントモデルを導入することで、様々なフレームワークで書かれたコンポーネントアプリケーションを開発していくとにしました。

Web Components について

提供をしている Web Components は自己完結型です。

そのため、コンポーネントは他のコンポーネントに影響を与えることなく修正し、アップグレードしていくことが可能です。

GDS は僕たちのチームで構築をし開発を行いましたが、ドメインの異なるチームでも積極的に利用をはじめています。

今までの GameWith の開発サイクルやリリースの仕組みなどと分離されているため、他のチームでも利用しやすいです。

例えば あつ森 (あつまれどうぶつの森) 攻略記事でリリースしたツール は GDS を利用して、攻略記事チームが開発をしました。

gamewith.jp

このあつ森のツールは GameWith というアプリケーション内にある、独立したフロントエンドアプリケーションのような動きをします。

以上のことから今後もGDSをGameWithサービス内でスケールさせていきたいと考えているので、このアーキテクチャによるメリット/デメリットを上げておきます。

メリット

  • iframe のような強力な分離。ネームスペーシングは不要です
  • グローバルスタイルが Micro Frontend に影響されないです。既存のアプリケーションとの連携が安全なので、追加的実装に最適です
  • CSS に関して ツールチェーン の必要性を減らせる可能性があります
  • フラグメント(Web Components)は自己完結型です。個別の CSS ファイルの参照はありません

デメリット

  • 古いブラウザではサポートされていません。ポリフィルは存在しますが、重くて、経験則に基づいた実装になっているため、根本解決にはなりません
  • 動作するには JavaScript が必要です
  • プログレッシブエンハンスメントはありません
  • サーバーサイドレンダリングは今、 Declarative Shadow DOM という仕様が策定されており将来的に気軽にできるようになるかもしれませんが、まだ一般的はないようです
  • 異なる Shadow DOM 間で共通のスタイルを共有するのは難しい
  • Bootstrap のようなグローバル CSS クラスを使用するスタイリングアプローチでは動作しません

デメリットへの解決策

GDS では @vue/web-component-wrapper を介して Vue の SFC 内で共通のスタイルを import しています。異なる Shadow DOM 間でのスタイルは、SFC をビルドすることによって共有可能となっています。

Web Components の各種ライフサイクルは、Vue のライフサイクルによって紐付けられているので、 Web Components の実装のソリューションが実現できています。

github.com

今後について

GDS が目指しているのは「どんなプロジェクトでも簡単に利用できる HTML コンポーネントの提供」です。

そのため、より中立的な Web 標準の技術を利用していくのを追求していきたいと思います。

現在の GDS から 提供される Web Components は、複数の Vue SFC をまとめてビルドするので、まだまだ粒度が大きいコンポーネントとなっています。

例えば、ボタンなどは Vue の SFC として存在していますが、ボタン自体が Web Components として提供されているわけではありません。

今後は、ボタンなどといった汎用的な細かいコンポーネントも Web Components として提供することで、Micro Frontend 化を進めていきたいと思います。

さいごに

GameWithのDeveloper向けTwitterアカウントも開設しました。
良かったらフォロー宜しくお願いします!

twitter.com

TypeScript と aspida で型安全に Vue.js の開発をしている話 #GameWith #TechWith

はじめに

こんにちは! GameWith の kuromoka です!

今回のブログでは、GameWith のダッシュボードの開発に、aspida という API のリクエスト/レスポンスに型を付与するライブラリを導入した話を紹介したいと思います。

ダッシュボードのフロントエンド環境については、Vue.js + TypeScript を導入しています。以下の記事も合わせてご参考ください。

tech.gamewith.co.jp

課題

前述の通り、GameWith のダッシュボードは Vue.js + TypeScript を導入しています。これまで API にリクエストするときは axios を使って以下のように書いていました。

async getPostData(): Promise<any> {
  const response = await axios.get('/api/post');
  return response.data.post;
}
async postPostData(title: string, text: string): Promise<any> {
  const response = await axios.post('/api/post', {
    title: title,
    text: text
  });
  return response.data.post;
},

この書き方には、以下のような課題があります。

  • URL の文字列部分を typo しても TS のコンパイルは通ってしまうため、実行するまで間違いに気づくことができない
  • 関数名と API のリクエスト先が紐付いていないため、関数名からどこにリクエストしているか分かりづらく、また API の種類が増えていくと命名に悩む
  • レスポンスの型を any にしているため、型安全なコードでなくなっている

これらの解決方法として、今年の3月に行われた Roppongi.ts #1 のセッションの1つに aspida を利用している話があり、そこで初めて aspida を知りました。

ちょうど今回の課題を解決するのに、aspida が利用できそうだったので導入することにしました。

aspida とは

github.com

aspida を使うと、以下のようなことができるようになります。

  • API のリクエスト/レスポンスに型を付与できる
  • API のリクエストを文字列ではなく、プロパティ経由で行えるようになる

aspida を作成した方の記事もあるので、こちらもご覧ください。

qiita.com

使い方

プロジェクトのルートに aspida の設定ファイル aspida.config.js を作成して、以下のように設定します。今回は dashboard/apis 以下を aspida の定義ファイルを置くディレクトリに指定しています。

module.exports = {
  input: 'dashboard/apis'
};

aspida ではディレクトリ構造と定義ファイルの名前が、そのままAPIのリクエスト先になるイメージになります。

たとえば dashboard/apis/api/post/index.ts に以下のような定義ファイルを書いた場合、 api/post で GET リクエストを送信するための定義になります、

dashboard/apis/api/post/index.ts

export interface Methods {
  get: {
    query?: {
      page: number;
    };
  
    resBody: {
      posts: {
        id: number;
        title: string;
        text: string;
      }[];
    };
  };
}

aspida では API 定義をした後に、以下のコマンドでビルドする必要があります。

$ aspida --build

ビルドすると$api.tsというファイルが生成され、今回の場合 dashboard/apis/$api.ts にファイルが生成されます。

あとは以下のようなコードで axios で aspida を使って、API リクエストを送ることができます。

import axios from 'axios';
import aspida from '@aspida/axios';
import api from './apis/$api';

const client = api(aspida(axios));

(async() => {
  const response = await client.api.post.$get({
    query: {
      page: 1
    }
  });
  response.posts.forEach(post => {
    console.log(post.id);
    console.log(post.title);
    console.log(post.text);
  });
})();

VSCode で確認すると、リクエスト/レスポンスの部分に、先ほど定義した型が付与されていることが確認できます。 f:id:kuromoka16:20200928183757p:plain

そのためプロパティ名が間違っていたりすると、エラーになるため間違いに気づくことができます。 f:id:kuromoka16:20200928185438p:plain

また URL にリクエストパラメーターが含まれる API の場合は、ファイル名に_から始まる変数名と@の後に型を指定します。型は numberstring の2つが指定できるようです。

以下は ID を指定する API で、api/post/1のような URL に DELETE でリクエストをするAPIになります。

dashboard/apis/api/post/_id@number.ts

export interface Methods {
  delete: {
    resBody: {
      status: 'failed' | 'success';
    };
  };
}

これを使う場合は以下のようになります(リクエスト部分のみ)。

(async() => {
  const response = await client.api.post._id(1).$delete();
  if (response.status === 'success') {
    console.log('success!');
  }
})();

IDは number のため、たとえば _id() の部分で string を送ろうとすると、エラーになります。 f:id:kuromoka16:20200928191130p:plain

テストコードの書き方

テストコードは Jest で書いています。aspida の部分のテストは、以下のように aspida のモックを作ってテストコードを書いています。

モックのデータ生成時に型補完を効かせるために、aspida から型情報を取得して利用しています(type PostTypeの部分)。

type PostType = ReturnType<typeof client.api.post.$get> extends Promise<infer T> ? T : never;
const mockPost = jest.spyOn(client.api.post, '$get');
const mockValue: PostType = {
  posts: [
    {
      id: 1,
      title: 'title 1',
      text: 'text 1',
    },
    {
      id: 2,
      title: 'title 2',
      text: 'text 2',
    },
  ]
};

// コンパイルを通すために any にしております・・・・・・
mockPost.mockReturnValue(mockValue as any);

// fetchPost 内で client.api.post.$get を実行している
const data = await fetchPost(1);

// ID = 1のデータをテスト
expect(data[0]).toEqual(mockValue.posts[0]);

今は aspida-mock というライブラリがあるらしく、これを利用することで今より楽にテストコードを書けそうなので、利用してみたいと思っています。

github.com

メリット/デメリット

apisda を使うことで、以下のようなメリットがあると感じました。

  • ディレクトリ構造がそのままリクエスト先になるため、分かりやすい
  • APIへのリクエストがプロパティ経由で書けるためコード補完が効き、またリクエスト/レスポンスともに型情報が補完されるので書き心地が良い
  • aspida は日本人の方が作成しているので、日本語のドキュメントがある

デメリットは GitHub のドキュメントは充実していますが、まだまだ利用例が少ないため、例えばテストコードを書くときなどに少し苦労しました。

終わりに

API 側とフロント側での型定義は連携が取れていないので、現在はそれぞれに型定義ファイルが存在しています。今後 Open API を使うなどして、二重管理になっている型定義を共通化していきたいと考えています。

またデメリットの部分でも書きましたが、aspida はまだ利用例が少ないと思っていますが、便利なのでもっと普及していってほしいと思ってます。

他のサービスでは今回のような場合にどのように管理しているか気になっているので、よければ Twitter でリプライなどいただけるとうれしいです!

Twitter

GameWithのDeveloper向けTwitterアカウントも開設しました。
ブログの更新情報などを発信するので良かったらフォロー宜しくお願いします!

twitter.com

VSCode Live Share がとても良かった話 #GameWith #TechWith

はじめに

こんにちは! リプレイスチームの @53able, @inosy22, @nog です!

今回は VSCode Live Share 使ってみたので感想など書いていきたいと思います!

使ってみたきっかけ

リプレイスチームでは、”開発で困ったらペアプロ(モブプロ)で解決する” という取り組みを行っています。

今までは Google Meet で画面を共有しながら、VSCode を表示して、Meet のチャットでコードを送ったりしてペアプロを行ってきました。

オンライン上でペアプロ(モブプロ)をしているときに、チャットでコードを送ったり、そのコードを口頭や文章で補足したりするのが全員がリモートだと特に非効率だったので利用してみました。

VSCode Live Share とは

docs.microsoft.com

ホストの VSCode のプロジェクトを共有して、リアルタイムで他のユーザーと共同で編集などができるツールです!

ホストの VSCode をリモートコントロールしている感覚に近いです。

できること

Share できるのは、プロジェクト内のファイル操作 or ターミナル操作ができます。

また、VSCode 内でチャットができます。

Participants でユーザーにチェックをつけるとそのユーザーの操作を追従するモードになり、カーソル位置や開いているファイルなどの操作を追従するようになります。

この追従の仕組は最初使い方がわからなかったのですが、共同編集をしているユーザーにチェックを付けて追従を開始することで、チェックしたユーザーの作業箇所にジャンプができ、並行して作業をしても迷子になることはなかったです!

ちょっと作業をして悩んだときに、他の人を今作業しているファイルに集まりやすくとても便利でした!

f:id:tiwu:20200821165209p:plain

導入手順

インストール

まずは plugin を インストールします。

marketplace.visualstudio.com

f:id:tiwu:20200821164950p:plain

アカウントの紐付け

Microsoft か Github アカウントでログインをします。

f:id:tiwu:20200821165028p:plain

Share 手順

URL を発行して共有することで Live Share ができます。

f:id:tiwu:20200821165122p:plain

実際に使ってみた

このブログを VSCode Live Share で書いてみました!

今までモブブログは google docs の共同編集を使っていました。

f:id:tiwu:20200821165307p:plain

良かった点

  • 状況により並行して開発を行えたり、柔軟にコミュニケーション取りながら開発ができるため、効率的に作業が行える
  • 口頭でファイルや行の指示するのではなく、追従の仕組みを使って自分が実際にファイルを開き共有ができるので、スムーズにコミュニケーションがとれる
  • 吹き出しの様なものでカーソルが表示されるので、誰が今どのファイルの何行目を修正しているか見やすい
  • ブラウザ上でも Live Share の共有ができるので、 VSCode をインストールしていない人でも共同作業ができる

難しかった点

  • ホストがエディタを再起動すると、作業が中断する
  • .gitignore に追記しているものは共有されず node_modules などが登録されていると、ゲスト側は node_modules が見えず補完が効かない
  • 同時に同じ箇所を修正していると、編集した箇所が消えたりして、操作の衝突があったりする
  • 共有されるのは VSCode なので、コード以外のブラウザの共有などのため Google Meet で画面共有は別途行った

まとめ

導入も簡単で、共有を受ける側も簡単にできるのでとても使いやすかったです!

以前のように、Meet で VSCode の画面を共有してペアプロをするより遥かに効率的でした!!!

ありがとう VSCode! ありがとう Live Share!

他のエディタにも同様な機能があると嬉しいな・・・!

Twitter

GameWithのDeveloper向けTwitterアカウントも開設しました。
もくもく会の告知やブログの更新情報などを発信するので良かったらフォロー宜しくお願いします!

twitter.com

GameWith メンバーのリモートワークデスク事情! #techwith #gamewith

はじめに

こんにちは! GameWith のエンジニアの tiwu です!

gamewith.co.jp

弊社は新型コロナウイルス感染症拡大に備えた在宅勤務(フルリモートワーク)を2020年3月30日から実施しています。

そこで、今回のブログは GameWith メンバーのデスクについて写真と一言コメントともに紹介していきたいと思います!

Tさん

f:id:tiwu:20200716173006j:plain

L字のテーブルを有効活用し、ウルトラワイドモニターを活かす匠のデスク。

Tさん

f:id:tiwu:20200716172932j:plain

モニター小さくて作業辛いので、モニターアームとディスプレイ注文中。

Kさん

f:id:tiwu:20200716172836j:plain

部屋の奥に横100cmのスペースがあったのでちょうど収まるように横100cmのデスクを設置。

電動昇降デスクを設置予定。

clas.style

Lさん

f:id:tiwu:20200716174332p:plain

大大大好きな彼女からもらったデスクがポイントです。

Tさん

f:id:tiwu:20200716175048j:plain

f:id:tiwu:20200716175111j:plain

ミクさん(とプラモ)。同じモニタでwindowsやswitchなどのゲームプレイできます。

Yさん

f:id:tiwu:20200716183303j:plain

最近デスク周りのライト設備を増やしました。

デスク裏にはLEDライト貼り付けて、その日の気分に合わせてムード変えたりしてます。

モニター裏にもライトライトを点けて置くことで、モニターの光と裏の影のコントラスト和らげてます。

Iさん

f:id:tiwu:20200720120848j:plain

ゲーミングPC系の機材環境に仕事用のMacを繋いでます。仕事モードとゲームモードを簡単に切り替えられるように頑張ってるので配線が汚い!

机全面のマウスパッドがかなり快適なので、マウスパッドは大きめがオススメです!

Oさん

f:id:tiwu:20200720160138j:plain

最後に

エンジニアやデザイナーに協力をお願いしたのですが皆さん個性的でそれぞれ最高のパフォーマンスが出るよう工夫されていますね!

Twitter

GameWith の Developer 向け Twitter アカウントを開設しました!

ブログの更新情報などを発信するので良かったらフォロー宜しくお願いします!

https://twitter.com/gamewith_devtwitter.com

エンジニアがオブジェクト指向 UI デザインに入門しています #GameWith #TechWith

こんにちは! エンジニアコミュニティでは、ごーと呼ばれている只野です。

tl;dr

今回は、弊社サービス開発エンジニア3名が オブジェクト指向UIデザイン(OOUI) という手法を学んでみて、所感を持ち寄りました。

オブジェクト指向UIデザイン──使いやすいソフトウェアの原理 から、キャッチアップをさせていただいております。

OOUI を知る前後の考え方は、人によって違うところがあるだろうと想像し、このことをテーマに話したら、デザイン手法を学ぶモチベーションが今後も高まることを期待して進行していきます。

よかったらお聴きください。

出演者

  • エンジニアマネージャー: serima
  • iOSエンジニア: かつらやま
  • フロントエンドエンジニア: ごー

編集後記

OOUI は、我々がよく使う OS で既に実現されています。

ユーザーは、作業フローに支配されているのではく、フレキシブルな方法で操作を成し遂げられるデザインであることが大いに便利であることがわかります。

今回の収録に向けて、オブジェクト指向 UI デザインを学んでみて、使い勝手が良いデザインをイメージできるようになったと実感しています。

UI を構成している部品それぞれを直感的に操作できることが、便利で欠かせない要素であると心から感じますし、サービス開発においても OOUI の手法で今後アプローチしてみたいと思いました。

再現性が高いであろう OOUI の手法は、サービス開発に関わる組織の誰にでもそうですが、特にエンジニアにはかなり親和性があるのではないでしょうか。

オブジェクト指向UIデザイン──使いやすいソフトウェアの原理 、お薦めです。

終わりに

GameWith の Developer 向け Twitter アカウントを開設しました。

技術やブログの更新情報などを発信するので良かったらフォロー宜しくお願いします!

https://twitter.com/gamewith_devtwitter.com

GameWith における CLB から ALB への移行 #GameWith #TechWith

はじめに

こんにちは!リプレイスチームの野口と @inosy22 です!

今回のブログは GameWith のロードバランサーを AWS の CLB から ALB に変更した背景や変更手順、詰まったところや解決方法について書いていきたいと思います!

リプレイスに関してはこちらの記事で紹介しています!

tech.gamewith.co.jp

ALB(Application Load Balancer)とは

docs.aws.amazon.com

サービス概要

ALB は、アプリケーションレイヤー (L7) でルーティング決定を行い、パスベースのルーティングをサポートしている高機能なロードバランサーです。

メリット

  • パスベースルーティング
    • URLのパスによって Lambda や EC2, ECS などに振り分けることができます!
    • 例:/api の時にAPIサーバー、/app の時にアプリケーションサーバーに振り分ける
  • リスナールール
    • URL のパス以外にも、IP や UserAgent で振り分けることもできます!
  • AWS WAF (Web Application Firewall) が利用できます!

なぜ CLB から ALB に変更をしたのか

主な理由はパスベースルーティングでリプレイスしたサービスに段階的に振り分けることをしたかったからです。

GameWIthが利用していた CLB では上記のような柔軟な振り分けが難しかったので、ALB に変更することにしました。

それ以外にも ALB だけでメンテナンス画面を表示する対応が完結したり、リスナールールで IP 制限など、メリットが多かった為です。

移行方法

1. ALB を作成する

ALB は ALB の作成画面で簡単に作れます。

しかし、CLB から ALB に移行する場合、CLB の画面から移行ウィザード経由で作る方法があります。

docs.aws.amazon.com

GameWith は独自のスケーリングシステムを構築しているので、CLB の移行機能ではなく、ALB 作成画面から ALB を作りました。

2. 独自のスケーリングシステムの改修

GameWith は EC2 の台数を独自のスケーリングシステムによって増減させています。

www.slideshare.net

このシステムを ALB に対応させるため改修を行いました。

詰まったところ

独自のスケーリングシステムは、ALB のリクエスト数によってスケールの基準を変更しています。(例:20万アクセスだったら20台)

CLB の時と同様に実装をしたところ、リクエスト数の取得を安定して行えませんでした(例:たまに取得できなかったり、取得できても0アクセスだったりなど)

CLB の場合は1〜2分前のリクエスト数であっても安定的に取得ができていたのですが、ALB ではそれがうまく動きませんでした。

そこで、リクエスト取得の時間を5〜6分前に変更してみたところ安定して値が取得できるようになりました。

いろいろと調査をしているなかで似たような問題を Google フォーラムで取り上げられているのを発見でき、解決の糸口となりました。

3. 移行前に ALB の暖気申請をする

暖気申請とは、予めスパイクが来そうな時間を AWS に伝え、CLB から ALB の切り替えによって瞬間的に増える大量の接続をさばけるように ALB のキャパシティを事前に上げておいてもらう申請のことです。(AWS サポートプランのビジネス・エンタープライズに入っているのが条件です)

今回の暖気申請の理由としては、GameWith はアクセス数が多いサービスなので、切り替えの瞬間などで落ちないように申請をしました。

実は暖気申請の存在を知らず、移行リリースギリギリに知りました。

知った当日に申請をしましたが、リリース日には間に合わず、リリースの予定を後ろにずらしました。

詰まったところ

ALB の暖気申請をする場合はマルチ AZ で配置をする必要があります。

GameWith の場合はシングル AZ だったため、暖気申請のためにマルチ AZ 配置をしました。

終わりに

これからサービスが成長する際に、パスベースルーティングが使えるようになりマイクロサービス化がしやすくなりました!

独自スケーリングシステムがブラックボックス化していたので、リファクタリングしバージョンアップができたのでよかったです!

暖気申請は忘れずに!(2回目)

GameWithのDeveloper向けTwitterアカウントも開設しました。

ブログの更新情報などを発信するので良かったらフォローよろしくお願いいたします!

https://twitter.com/gamewith_devtwitter.com