〇参加セッション
-技術選定の審美眼
-属人化したフロントエンドのJavaScriptを、‘新規機能開発を止めずに’改善するために行った取り組みについて。及びその経過報告。
-Spinnakerで実現するデプロイの自動化
-自然言語処理・機械学習を活用したファクトチェック業務の支援
-VMware運用を10年続けてきた今だから言えること ～VMware vSphereベースのパブリッククラウドが乗り越えた壁～
-タウンワークをドライブさせるためになんちゃってアジャイルをやめた話
-さらばダミーデータ！～超高速開発を実現するテストデータ活用～
-音声UIはアプリ開発の何を変えるのか？ スマートスピーカーアプリ開発者大集合！
-IoTサービスを始める際に必要なこととは（仮）
-Apache Kafkaによるスケーラブルアプリケーション開発
-大規模ログ集約実現のためのアーキテクチャ～誰でも美少女になれるVRシステム「VR Live Studio」からお届け
-加速するフロントエンドとPWA
-エンジニアが本音で語るGitHub Enterpriseの導入効果
-Swaggerを使ってPHPエンジニアとUnityエンジニアがもっと仲良くなった話
-NoOpsを目指すgumiのインフラ自動化ツール
-企業がAIに本気で取り組むための組織づくり
〇技術選定の審美眼
-要約
様々な技術（開発手法やフレームワークなど）が新しく登場してきている。最近は特にJavaScript界隈の変化が早い。
ただし、「変化が早い」ということは「陳腐化が早い」ということであり、実質消えてしまう技術も多いということである。
従って新しい技術を全て追っていては無駄であるが、だからといって重要な変化（技術）を見逃すと取り残される。
新しい技術の登場は大きな変化ばかりでなく、一見すると同じことを繰り返しているようなものも多い。
しかしその場合でも、使用の容易さや効率性など実際は過去のものから多少の進化はしている。
技術の本質的な重要性を見分けるには、変化の差分を理解し、どのような技術、仕組みで実現したかを把握することが重要である。
近年の重要な変化は次のようなものが挙げられる。
・クラウド
・シェアドナッシングとスケールアウト
・コンテナ技術
・React (仮想DOMにより現状の表示に関係なく次の出力を決定できる)
・Rails (「設定より規約」により高速に開発できるようになった)
大きな変化の流れとしてはWEB関連技術へ流れており、特にモバイル関係に収束している。
PWA(Progressive Web Apps:Webとアプリケーションの良いところを組み合わせたWebページ)はその１つである。
※参考:https://developers.google.com/web/fundamentals/codelabs/your-first-pwapp/?hl=ja
更に、GraphQL、Swaggerは注目すべき技術である。
過去から現在で特に重要であった変化には次のようなものがある。
・UNIX系OS
・REST/WEB
・RDBMS/SQL
上記の３つの技術に共通する特徴を以下に挙げる。
・インタフェースが狭く限定的
・振る舞いの種類が少ない
・実装に依存しない
また、上記の３つの技術は極端に言えば、「全ては○○である」と言い切れる。
・UNIX系OS … 全てはファイルである：プロセスやデバイスなどをファイルと共通の処理方法で扱える
・REST/WEB … 全てはリソースである：URL（とHTTPメソッド）を変化させるのみでアクセスや結果応答の方法は同じである。
・RDBMS/SQL … 全ては集合である：数学の集合理論を背景に処理できるので、ロジックが強固である。
これはシンプルであるとも言える。
なお、シンプルと簡単は同じではない。
「簡単」は手数を少なく使用できることであり、大抵それに反して覚えることが多くなる。
「シンプル」は反対で、手数が多くなるが、学習コストは低い。
シンプルな技術ほど、インターネットの検索は少なくなるので、Googleトレンドで上位の技術が必ずしも良いものであるとは言えない。
-所感
シンプルさを考える際、誰にとってシンプルであるかも考えた方が良いと思う。
開発エンジニアにとってシンプルでなくとも、保守エンジニアやユーザーにとってシンプルであることも成功の要因となりうる。
PDFはその一例である。
〇属人化したフロントエンドのJavaScriptを、‘新規機能開発を止めずに’改善するために行った取り組みについて。及びその経過報告。
-要約
JavaScriptのコード量が増加するにつれ、属人化してしまったため、保守が非常に困難になった。
その改善のために取り組んだことを紹介する。
・Reactの採用
以前はjQueryを全面的に採用していたが、トリガーとイベントの処理を分けて書く必要があり、更にトリガー設定の際に渡すイベント関数を変数化して渡していたため、対応が非常に把握しづらかった。
※書くこともできるが、読みづらい。
Reactを使用して整理しなおすことでトリガーとイベントの対応が明確に記述できるようになった。
・Webpackの採用
特定クラスの特定関数をデバッグする際に、その関数がどのファイルに記述されているのかを探すのに非常に時間がかかっていた。
これはWebpackを採用することで、import文でどこを参照しているかが一目でわかるようにできた。
・ESLintの採用
グローバルに存在する名前空間を確認するのが自動ではできなかった。
ESLintを導入することにより、グローバルに存在する名前空間を見える化することができる。
これにより、var、let、constの付け忘れの防止もできる。strictモードでもvarなどの付け忘れは実行時エラーになるので検出できるが、Eslintでは実行前に見つけられる。
・JSDocの採用
JSDocを使用してコメントを書くと型チェックを行うようにした。
・どのように改善に取り組んでいったか
まずはページ単位のReact化を目指した。
いくつか手が付けられないものもあるが、React化が済んだページは改修がしやすくなる。
〇Spinnakerで実現するデプロイの自動化
-要約
Spinnakerとはアプリケーションのデプロイツールの一種。
後発のため、豊富な機能を持つ。
特にツール自体でマルチクラウドに対応している点が特徴で、追加開発なしに主要なクラウドサービス（IaaS,PaaS）にデプロイできるのはSpinnakerが現時点では唯一の選択肢である。
デプロイ方法も多様でBlue-Green Deploy、Rolling Deploy、Canary Deployも対応しており、戻しも可能。
※Blue-Green Deploy：デプロイの度にサーバ群をもう１セット用意し、新しいサーバ群にデプロイする。デプロイ完了後、一斉に切り替える。デプロイ前のサーバ群も残しておくことで、障害時にすぐに戻すことができる。SpinnakerではRed-Black Deployと呼んでいるが、内容は一緒。
※Rolling Deploy：一定数のサーバを切り離し、デプロイ完了後にサービスインする。それを全台完了するまで繰り返す。大量のデプロイ前、デプロイ後のサーバが混在してしまうが、デプロイ後のサーバを早期にテストしやすい。
※Canary Deploy：一部のサーバのみデプロイし、問題なければ残りのサーバもデプロイする手法
デプロイを完全自動化可能であるが、Spinnaker自体の起動はJenkins等からキックする必要がある。
Jenkinsと連携することで一つの画面でgithubへのアップから本番環境へのデプロイまで可能。また、デプロイに失敗したノードを分かりやすく確認することもできる。
デメリットとして、まだ開発途上な面があり動作が不安定なことがある。ただ、バージョンアップの勢いは良い。
AWSで使用する場合、制約が存在する。
まだドキュメントが少ない。
-所感
クラウドサービスであろうとベンダーロックインを避けることは重要であると思うので、改修不要でマルチクラウドに対応しているというのは良いと思う。
ただ、システム全体の構成要素としてはデプロイツールの比重はそれほど高くない。
デプロイツールの評価点として、デプロイのスピード、機能性、導入の容易さが特に重要だと考えるが、安定性に懸念があるのは残念。
〇自然言語処理・機械学習を活用したファクトチェック業務の支援
-要約
ファクトチェックはSNS等で発信された情報が信用できるかどうかを評価すること。単に文章の論理性、整合性を検証するのではなく、真偽をチェックする。
PolitiFactというWebサイトが有名。
今回紹介するのは、ファクトチェックを人工知能により行う取り組みについて。
現状開発はTwitter情報をインプットとして、アウトプットは事実か誤情報か不正確かのいずれかである。
Word2vecモデル（※ニューラルネットワークの一種）を利用して別途学習させておいたデータを組み込んでいる。
Word2vecの学習にはgensim（※トピック分析ツール。文章のカテゴライズを行う。）を利用する。
時系列データの学習としてはLSTM（※ニューラルネットワークの一種）を利用している。
学習データを用いて、新しいTweetの特徴ベクトルを算出、正解の確率予測を出力する。
（※本当っぽいTweetと、嘘っぽいTweetの文章上の特徴を挙げておき、新しいTweetが本当っぽい方の特徴を持っているのか嘘っぽい方の特徴を持っているのかを出す。その際、１つのTweetだけでなく、一連のTweetを合わせて考えることで精度を上げている。出力は本当か嘘かの２つではなく、何％位本当っぽいかという大まかなものである。ということ。）
実装の際、Prediction APIという機械学習用のWeb APIを使用している。
〇タウンワークをドライブさせるためになんちゃってアジャイルをやめた話
-要約
リクルート社の求人情報サービス「タウンワーク」の開発でアジャイル手法をやめた理由を紹介する。
元々はリリースのリードタイムを改善したくて導入したagile開発である。
しかし、導入してから一定期間後リードタイムの改善を計測してみると、効果があまり現れていないことが判明した。
Agile開発のルールに則ることが目的になってしまっていたのが原因。
リードタイムを可視化し、効果を早期に測定可能にした。その結果、Agile開発が必ずしも適切ではないことがわかった。リードタイム悪化の最大の原因としては、バックエンド開発者からフロントエンド開発者への手戻りであった。仕様の明確化、情報連携の改善で解決した。
結局、手法ありきではなく、目的を見定めて地道な改善を図ることが効果的であると言える。
〇さらばダミーデータ！～超高速開発を実現するテストデータ活用～
-要約
データベースが関わる開発、チューニング、トラブルシューティングは本番データに近いデータを使うほど効率的に行えることがわかっている。
しかし、本番データを開発用に利用することのセキュリティ問題や、即時に本番データのコピーを検証環境に準備することは困難である。
Delphixを使用することで解決することができる。
Delphixは本番データベースと常時同期し、任意の時点のデータのスナップショットをDBサーバの仮想インスタンスとして提供する。
Delphixはデータベースを提供する際にデータのマスキングを自動で行うようにすることができる。
また、データベースサーバのインスタンス生成を非常に高速に行うことができ、試験を何度もやり直すためにデータを戻すことも容易である。
-所感
デモが行われたが、非常に高速で、1分かからない程度で仮想インスタンスの作成が完了した。
データ量がどの程度であったか不明であるが、高速そうに見える。
使用も簡単そうで、非常に便利そうであった。
一度検証してみたい。
〇IoTサービスを始める際に必要なこととは（仮）
-要約
下記IoTサービスの紹介がされた
・あぐりログ
農場監視システム
・まごチャンネル
遠隔地の人に映像・写真を送り、見てもらえる。
・soracom
IoTプラットフォームサービス
〇Apache Kafkaによるスケーラブルアプリケーション開発
-要約
Apache Kafkaとはメッセージブローカーの一種でRabbitMQ等と同じタイプのミドルウェアである。
次のような特徴を持つ。
・永続化
・レプリケーション
・データの再取得可（データを一度取得すると消えるタイプのメッセージブローカーもある）
・ビッグデータ対応
・メモリだけでなくファイルシステムも利用可能
・ストリーム処理可能
・Apache ZooKeeperによる分散基盤を実装
・トランザクション対応
・REST、SQLでアクセス可能
アイスタイル社のWebサービス「＠cosme」では高速に動作している。
ElephantDB、Splout SQL、PipelineDB等のデータベースと連携できることを確認している。
ただ、Apache Kafkaからデータを取りだし処理した後のデータベースはCassandraが最も扱いやすかった。
Apache公式版の他に高機能に拡張開発されたConfluent版の方があるが、後者の方がおすすめ。
メッセージブローカーは古い技術でOSSもいくつかあるが、特にStream処理が必要ならKafkaのみ
-所感
MQサーバでストリーム処理が必要になるシーンは思いつかないが、コネクション処理は負荷が高いので、Stream処理ができることは強みになりうると思う。
割と最近、バージョン1がリリースされたようなので、他で要件が充足するならあえて使う理由もないとは思う。
〇大規模ログ集約実現のためのアーキテクチャ～誰でも美少女になれるVRシステム「VR Live Studio」からお届け
-要約
gumi社の各種ゲームでのログ収集基盤ではfluentdを各サーバにインストールしてログサーバに一旦収集していた。
そこからログサーバ内でデータの加工の後、データベースに再投入をしていたので、負荷が高く、障害時に全体が停止してしまっていた。
そこで、ログ収集基盤を再設計することとなった。
gumi社ではAWSを使用して、インフラを構築していたので、AWSのPaaSサービスである
「Kinesis」でログ収集を、「Lambda」で一次処理を行うことにした。
「Kinesis」、「Lambda」の良いところはAWS管理のサービスであるため、ユーザー側で管理の必要がなく、高負荷時にオートスケールすることである。
-所感
内容よりプレゼンテーションで使用されていた3DアバターソフトのVR Live Studioに感心した。合成音声も使用可能とのこと。
応答性も高く、再現性も高いように見受けれられる。
遠隔地の人同士でバーチャル会議ができるそうだが、インターネットを介した場合の遅延はいかほどなのか。
〇加速するフロントエンドとPWA
-要約
PWAとはProgressive Web Appsの略であり、Webとアプリケーションの良いところを組み合わせたWebページのことである。
その主要な技術の１つがService Workerであり、Service WorkerとはWebブラウザ、サーバ間で動作するローカルプロキシのようなものである。
Service Workerにより、レスポンスの書き換え、オフラインキャッシュ、バックグラウンド処理、プッシュ通知が可能となる。
生存期間はリクエストから15～30秒程度であり、メモリ使用料も制限されるため、リスク対策もされている。
非常に強力な機能であるが、最大の問題は今だ大きなシェアを誇るIEでは使えないことである。2025年がサポート終了期間であるが2020年にはEdgeへ大きく移ると考えている。