新しい技術を取り入れるための実験のやり方 〜サーバーレス・機械学習・PWAを実戦に投入するまで〜 に参加しました
火曜日の夜、イベントに参加しました。
と言っても、富山に住んでるので現地に行けるわけもないんですが、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も、特定用途に限れば、かなり使える。積極的に使っていきたい。