アメリカスタートアップ開発こぼれ話
イントロ
スタートアップエコシステム第二弾です。
インドで立ち上げたサービスの大部分に関わったので、折角なので日本語で解説してみたいと思います。
どんな感じで開発したのかの経験談のような文章ですが、私の背中を見て育つ次世代の人がいたら幸いです。
個人的な見解なので会社の公式発表ではありません。
サービス概要
インドで立ち上がったサービスは一言で言うと、インドで使えるGoogleペイの機能の一部として空港向けサイトをPWAで提供したという事になります。
インド空港に出入りしているTFSというベンダーの多店舗向けに提供したので、既に複数のインド空港で使えるようになった事からもわかるように、Googleペイユーザのショッピング体験を空港単位に簡単に導入する事ができるようになりました。
例えばチェーン店向けのアプリは一部日本でもありますが、店舗やチェーン店単位で開発するのではなく、複数の空港やショッピングモールで使えるようなwebアプリをGoogleと連携してリリースしたイメージです。
PWA（Progressive Web Apps）はスマホアプリを開発しなくても、各種スマホで簡単に使えるようになるwebアプリです。
ブラウザでもスマホアプリ上でも同じ仕組みで動かす事ができるので、Androidや iOSどちらでも簡単に使う事ができるようになるはずで、アメリカとインドで先行して始まりました。
苦労した点
今回1番大変だったのはGoogleペイ上でテストを実施するためにインドに滞在する必要がありました。
コロナで誰もインドに行けないという条件下に関わらず、今回は優秀なインド人がリモートワークで3ヶ月位で開発してくれたのですが、本番環境での動作確認含めたテストまで大活躍だったと思います。
開発チームと開発期間
開発チームの内情ですが、日本では考えられない位人数少なく、開発責任者が東海岸のアメリカ男性、UI/UXが西海岸のアメリカ女性、コーディング担当がインドのバンガロールのインド男性、その他なんでもやれる川崎市在住の日本人男性という4人体制でした。
今年の8月から11月の4ヶ月という期間で週2回くらい日本時間の夜中の12時半から定例会、定例会後の個別打ち合わせがありました。
基本的にコロナの影響もあり、自宅でリモートワークする生活をひたすら繰り返していました。
この期間スマホのパケット制限を意識せずにオンにしていたのですが、最近まで気づかないくらいwifi環境生活だったようです。
技術的な内容
もう少し技術的になりますが、PWAだけだと大量アクセスやサービスダウンなどに対応出来ないためインフラ側との連携が不可欠です。
Googleペイ経由のユーザ数増加、PWAの複数拠点の提供などを想定した場合、インフラ周りが頭打ちになる事は事前に明白でした。
また、PWAを開発する側は手動でセットアップしていたので、インフラ側のテストを含めた同時開発だとインフラ側はPWAが完成するまで手付かずになりそうだとも感じていました。
当然の流れで、インフラ環境を至急準備する必要があったのですが、たまたま私がメインに活動しようとして、ある意味寝かせていたマイクロソフトのスタートアッププログラムのAzure環境を全面的に活用する事になりました。
私自身PWAを触った事は無かったので、PWAのリポジトリをクローンして自分のローカル環境て試してみる事から始めてみました。リポジトリには手順書がわりにコマンドが2個だけ記載されてるという状態でした。
ググって色々情報を集める事でなんとか動かせるようになりました。本当に動くのかわからない状態からでしたが、ローカル環境だとPWAに繋がるAPIに上手くアクセスできないからローカルにAPIサーバを立ち上げてみたり、ようやくローカル環境でも動くようになってきました。
技術的な課題解決や泥臭かったこと
しかしながら、PWAとそのAPIがものすごい勢いで日々アップデートされていくので、それに合わせてインフラ側を最適化するなどの開発作業が気が狂いそうなほど負荷が高まっていくのがわかりました。
そんなわけで、PWA側とインフラ側双方をコンテナ化して、どの環境でも同じ動作可能な状態で開発しようと決心しました。
コンテナ化する事で比較的に容易にAzure上にプロトタイプは動かせましたが、Googleペイ上に登録したPWAのサブドメインを固定する必要があったため、容易にプロトタイプをGoogleペイ上で試せないという、問題にぶつかりました。
サブドメインを使っていたサーバはインド男性開発者のAWS環境だったため、私が作った環境に切り替える必要がありました。
切り替えようにもGoogleペイの確認テストが平日に進行中だったので、切り替え失敗してしまうとサービスが止まるかもしれないと、金曜日のインド時間の定時後誰もアクセスしとない事を確認しながら切り替えてみました。
切り替えたところブラウザでは見えていたサイトがアプリ経由だとエラーになっているらしいと言うことで、明け方近くまで皆んなでデバッグしましたが、無事に切り替えできたのは1番の思い出となりました。
エラーの原因はPWA側でビルドしたファイルをパイプライン上でコピーミスしていたらしいというオチでした。。
コンテナでプロダクトが無事に動きだしたタイミングで、本格的にパイプライン化を進める事で、人手で2週間はかかりそうなPWAを製品版としてリリースしたり、アップデートするのに30分かからなくなりました。
リポジトリの管理やパイプライン処理はgitlabというオープンソースですべて運用していてgitlab runnerをAzure上で動かしています。今のところ私の代わりに24時間働いてくれるようになりました。
チーム開発の最適化
ここまではdevopsという開発と運用が一体化する手法を採用する事で高速にプロダクトリリースが可能になりました。
とは言ってもプロダクトをリリースする際にはセキュリティーやパフォーマンスを気にする必要がありました。
プロダクトで使うnginx のアクセスログを見ると大量に不正アクセスを受ける可能性が高い状態だと気づきました。
恐らくJavaやPHPの脆弱性を常に試しているようなアクセスがほとんどだったのですが、PWAで使っているnodejs やnginxのコンテナはセキュアなんだろうかと不安になりました。
更に負荷をかけたらどのくらい性能劣化があるのか評価したいと思いました。
コンテナがセキュアかどうかは別途確認する事はできるのですが、今回インドプロジェクトて手動でセキュリティチェックしたり性能評価しました。
その結果を踏まえて高速にアップデートする事になったらインフラ側がボトルネックになりそうだと思いました。
そんなわけでdevsecopsという新しい概念を開発現場に導入してみました。
作ったPWA側もセキュアだという事がリアルタイムにわかるようになりました。
さらにどの位の負荷まで現状耐えれそうか見えたので、インフラ側はKubernetes対応が決まりました。
Kubernetesを導入した場合にPWA側に確認すべきポイントも事前に把握する事ができたので、近日中に導入出来そうな気がしています。
Kubernetesはコンテナを負荷に応じてリアルタイムに増やしたり減らしたり可能なオープンソースの仕組みです。
今後の展開
今後ユーザ数、提供店舗数、提供リージョン数などの増加に対して自動で対応するような技術を突き詰めていきたいと思います。