新しい技術を取り入れるための実験のやり方 〜サーバーレス・機械学習・PWAを実戦に投入するまで〜 に参加しました

火曜日の夜、イベントに参加しました。

guildworks.doorkeeper.jp

と言っても、富山に住んでるので現地に行けるわけもないんですが、Zoomでの参加が可能だったので登録してみました。

久しぶりの平日夜の勉強会でした。

内容としては、ギルドワークスが1ヶ月4名ぐらいで、いろんな新規技術を詰め込んだ自社プロダクトWebアプリを作成、そのときの知見共有、といった感じ。

個人的には、「受託の実案件にどうやって新技術を突っ込むか」を聞きたかったのですが、話を解釈すると「実案件にいきなり突っ込むのは難しいから、先に小さめのアプリで一度やる」なのかなーと感じました。

個別の技術の話は、下のメモに書いたとおり。知ってること半分、知らなかった・再認識した話半分、という感じ。

運営に関しては、珍しいZoomでの配信ということでしたが、概ね良かったと思います。(上から目線。。。 マイクオンのまま入ってくる参加者がおり、最初だけはホスト側の対応が遅かった気がしますが、それ以降は快適に聞けました。 (弊社の全体会議も、これぐらい上手く進めばいいんですが。。。)

欲を言えば、スライド以外に会場の様子・スピーカーを映したカメラもあったら良かったかも?と思いました。

あと、ハッシュタグも決めてもらったほうが、Twitter上で盛り上がってよかったのでは?と思いました。 (Zoom配信に結構な人数いたので、そこも含めた一体感も出やすいかなーと。)

地方在住者はなかなか勉強会に参加できないので、こういったリアルタイムの配信が増えてくるといいなーと思います。(設備とか大変だろうけど。。 最近はYoutubeとかでアーカイブ配信も多いですが、「いつでも見れる」状態ってなかなか見ないんですよね。。。 そういった意味でも、リアルタイムで他の人も聞いている、という状況がいいなーと思います。

以下、メモ。

リスク
技術のリリーススケジュールに、デリバリーが引っ張られる。

漸進的な改善と根本的な転換
取り入れやすさを取るか、大きなリスクを取るか

ギルドワークスでは
GraphQLを一部利用、SPAを部分的に利用などしている。
React Nativeを全面採用しようとしたが、速度が出なかった。

やりたいこと=根本的な転換を、低リスクで実行
新規自社プロダクトのMVP開発を対象にする。

AWS Elastic Beanstalkを使ってる。
Spring/Spring security, Rails/deviseを使っている。

課題
ボイラープレートコードが多い。(データのCRUD/認証など。微妙に違う。)
フロント開発が3ターゲット分必要。

今回の挑戦
SaaSで外部に出す。Cognitoの利用。
大きなフレームワークから、Lambdaへ。
PWA(Ionic)

Lambdaを利用しようと思うと、SPA->API Gatewayや、DynamiDBが必要になってくる。

## Lambda + Java

LambdaでJavaを使う理由
言語として利用したことがある。リスク低減。
Lambdaでのサポートしては歴史が長い。安心感。

課題
DynamoDBの利用。RDBのように扱う。
AWSのデプロイなどは、AWS Toolkit for Eclipseを利用。とっつきやすかった。

DynamoDBの利用
DynamoDBMapperが標準である。入れ子のデータ構造などもサポートしてる。
JPAなどと同じように使える。

デプロイ
AWS SAM形式のテンプレートから、Eclipseでデプロイする。
BluePrintがいくつか用意されていて、ウィザードもある。
AWS Toolkit for Eclipseは、GUIでとっつきやすい。コマンドでの再現も出来る。

認証
Cognitoでクライアント認証。
API Gatewayでヘッダを見て弾く。
Java側では、認証チェックなどは行わない。

ステージング環境の構築
DynamoDBの扱いがアノテーションベースだったので、テーブル名の付替えが難しい。
別リージョンでステージング環境を構築した。ベストではないけど、ちゃんと動く。

Java+Lambdaの問題
起動が遅い。出来るだけコンパクトにしても10秒などかかる。
ポーリング?ローディングのタイミングを工夫?ユーザからのAPIはJavaを避ける?
Goで再実装中。

純粋なJavaになるので、テストコードは書きやすそう。ただ、今回はDynamoDBとのIn-Outだけなので書いていない。

1週間スプリントのスクラムで実施。大きな問題があれば、検知が出来たはず。(今回は、特に出なかった)

## Ionic

Angularをベースに、UIコンポーネントが充実。
cordobaと連携することで、アプリ化も出来る。
ドキュメントが丁寧。(インタラクティブなドキュメント)
CLIのサポートが充実。(Angularを踏襲)

標準テンプレートで作成すると、Service Worker設定済み。
ファイルキャッシュ、APIのキャッシュが簡単に設定できる。

Ionicを使う上でのポイント
CLIを出来るだけ使う。構成を保って、generateが出来る。
TypeScriptの型定義を利用する。ミスを防ぐ。

Ionic標準から外れるUIの作成は高コスト。
標準で使うのが良い。作る場合も、Web技術で作ってしまうほうが楽。Angularの資産も使える。

クライアントでのCognito認証
AWS Amplifyを利用することで、認証コードの作成が楽になる。

## 機械学習

導入の難しさ
データセット足りない。最低でも1k程度のデータが必要。
技術的ハードルの高さ。数式などが必要。

今回のスタンス
データセットが集まっている分野に絞る。Googleなどが学習済みのものなど。
画像認識・言語分析・音声認識
技術的ハードルについては、SaaSをフル活用する。

Google Natural Language APIを利用。日本語に強い。

都度実行すると高いので、バッチで叩いたほうが安い。

## トライしたこと

4人で1ヶ月。そこまで大きくない。
やったことないことを詰め込んでやっている。
リリース前提なので、実際のプロジェクトに向けた知見を得られた。

次の実験に向けて
MBaaSにチャレンジ。Google FireStore / AWS AppSync。
Ionicの他に、React/Vue.js や ReactNative/Nuxt。
機械学習もSaaSからPaaSへ。AWS SageMaker。

方針決定は、オフラインで集まってやった。2,3時間。
受託だったら、今回ほど大規模に新しいことはやらなかっただろう。ただ、今回の知見があるので、次以降で一部導入などは出来そう。
今回の開発で懸念も出てきたので、次の自社プロダクトで別の方針を試す。
Cognitoはかなり使えた。DynamoDBも、特定用途に限れば、かなり使える。積極的に使っていきたい。