[エンジニア情報収集]Developers Summit2020 1日目(2/13)メモ

2020/02/13

DevelopersSummit2020のDay1に参加したのでそのメモです。
（@ホテル雅叙園東京）

LPICブースのノベルティ。とってもかわいい。さっそくラバーペンギングに使ってます

アプリケーションやシステムが悪いやつらに攻撃されたらどうなる？

synopsys
松岡氏

サイバーインシデントはなぜ起こる？
- Allianzビジネスリスクバロメーター2019
- サイバーインシデントはすでにトップ要因
- 発生理由
- システムの脆弱性
- システムの誤設定
コード量が増えればリスクは増える
自動車リコールが増えている、制御プログラムの不具合が影響大
- 自動車はソフトウェアの塊
生命の危機、社会インフラの停止、情報漏洩
- 737MAXの事例
現代のソフトウェア開発の課題が増え続けてきている
- コード量
- 複雑度
- 開発速度
- リスク
ソフトウェアの脆弱性は急速に増加
- 2017年以降、大幅な増加
- 保守を停止すれば脆弱性は増えていく
よりセキュアなアプリケーションの開発
インターフェースから脅威を考える
- NISTの情報を参照
脆弱性は常に増え続ける（見つけてくれるひとがいるから）
- CWE、CVE
脅威モデル
- それだけでお金がとれる
OWASP
- チートシート
脅威モデルを考えるまえに、まずリソースを把握する
coverityでCWEを検知
- 静的解析

GKEを本番環境で利用するまで

株式会社grasys

GKE：GCPで提供されているk8sのマネージドサービス
K8sのmanifest管理はkustomize
- lustomize
- 開発環境と本番kん今日で異なるパラメータ（環境変数）の適用が可能
- configMapGeneratorが便利
InfluxDB → Grafana
インフラの会社なので、プログラムは外注している
GCPゲームインフラ構築ガイド

質とスピード

和田卓人氏
- Twitter @t_wada
- はてな @t-wada
- GH @twada

写真を撮るならMicrosoftPicsがおすすめ

すべきことが多い
時間、予算、品質、スコープ
品質が犠牲にされることが多い
- 短期的には◯
- 中期的には逆効果×
- 長期的には致命傷×
品質とは？
- 誰かにとっての価値（Gerald Weinberg）
- ilities
狩野モデル
- 当たり前品質（基本）
- 魅力品質（あったらいい）
- 一元的品質（あればあるほどいい）
見える品質と見えない品質
- 外部品質と内部品質
- 内部品質をつくりこむことで外部品質に近く
内部品質→保守性
保守性とは
- 下記の容易性
- テスト
- 理解
- 変更
保守性を犠牲に捧げるとどうなるか？
「リリースが先」とすると、結局保守をしなくなる
- コードが荒んでいく
会社が存続する限り、スピード優先になるので、保守性を後回しにすることは、荒んだコードが蔓延していくばかり。「あとでやる」＝「やらない」
- 保守性の低さ（=技術的負債）
スピードを落とせば保守性はあがるか？
- あがらない
- つまり、スピードと保守性はトレードオフではない
能力のあるひとはスピードを速くしてもそれなりの質のものをつくる
何かにつけてトレードオフ構造を見出して、妥協する「トレードオフおじさん」
実質無料
- 「品質向上のためのコスト」が「品質向上の結果減るやり直しにかかるコスト」を上回る
スピードから質への影響はどうか？
- リードタイム
- リリースしてから使用開始までの時間
- デプロイ頻度
- MTTR(平均修復時間)
- 障害復帰
- 変更失敗率
- 内部品質がスピードを生み
- スピードが学びのループを生み
- 学びのループが外部品質を生み
- 外部品質が競争力を生み
- 競争力が売り上げを生み
- 売上が内部品質を育む
どうやって個人の質をあげるか
- FBの伝説のプログラマプレスリーさんの言葉
- 自分ひとりでシステムをつくり、そのメンテナンスをしてみることが一番かも
内部品質への投資の損益分岐点はいつくるのか？
- テスト自動化の損益分岐点は4回
- およそ4回で手動テストと自動化されたテストのコストは逆転する
- 内部品質への投資の損益分岐点は1ヶ月以内
- 自分たちの損得に大きく関わる
与えられた時間でおおくをやるには
- スコープを削る（＝機能数を減らす）が答え
スピードと質は何とトレードオフなのか？
- スピードをあげるなら、おっさんがよってたかって開発すれば早くリリースできる。しかし、若者が育つ、チャレンジする機会がなくて、組織としては衰退する。
- つまり、トレードオフなのは教育、成長、多様性への投資

資料

本日の講演資料を公開します。初演からかなり改訂した「質とスピード」最新版の資料です #devsumi #devsumiB / “質とスピード（2020春版） / Quality and Speed 2020 Spring Edition - Speaker Deck” https://t.co/nqvV0nmd8b

— Takuto Wada (@t_wada) February 13, 2020

Googleにおける「ソフトウェア×インフラ」デザインマイクロサービス・アーキテクトの視点から

Google合同会社クラウドソリューションアーキテクト
中井悦司氏

GCPの魅力とは？
- GCPのコンセプト
- Googleのソフトウェアエンジニアと同じ体験を一般のデベロッパーにもパブリッククラウドとして提供
- 世界中の情報を整理し、世界中の人々がアクセスできて使えるようにする
- 専用回線によるグローバルネットワーク（インターネットでない）内部のデータパケットはすべてGoogleのエンジニアが管理。速度が安定
- Datacenter as a Computer
  - コンテナによるアプリケーション管理
  - Datacenter as a Computerが実現される
- 共通ミドルウェアサービス
  - 各種分散基盤
- Google社内ではマイクロサービスという言葉は使われない
  - Google的には当たり前、当然であるので、あえてマイクロサービスとは言わない。マイクロサービスが流行るまえからマイクロサービスアーキテクチャをやっていた
どうマイクロサービスをデザインしていくか？
マイクロサービスWebアーキテクチャ
- BFF (Backend for frontend)
- 外部に見せるAPIと後ろ側で管理するものを分離する
- 基本的にさまざまなものが共有される（リソースの効率化）
既存アプリのマイクロサービス化
- マイクロサービスで開発する利点
- ひとつひとつの仕組みをAPIとしてサービス単位で作成
- 機能単位で作成、粒度を小さく保つ
- チーム間の依存関係を減らす
- システムの複雑さは優秀な人知を容易に超越する
- 変更容易性、依存関係がない
  - 想定外影響を減らす
- マイクロサービスによるスクラッチ開発の課題
- 将来が不明であるのに、将来の機能拡張に備えた実装が必要
  - 非常に難しい
- Monolith to Microservices
- 既存アプリがMVCモデルで実装されていて改修可能なら
- オンプレミスで塩漬け
  - BFFで既存システムを抽象化して機能単位でリプレース
  - 既存システムにBFFレイヤをかませる
  - BFFで各種機能をアグリゲーションしていく
- マイクロサービスによるシステム設計とは？
- アプリケーションの機能を適切にマイクロサービスに分割する作業

テストコード

株式会社ビズリーチ
風間氏

テストの目的
- 欠陥の検出
- 意思決定のための情報の提示
- 欠陥の造り込みの防止（実装の前に行うテスト）
- テストは「欠陥がある」ことしか示せない
- お互いに気づかなかったことを知ってはいないか？
どうやってテストケースをつくるのか？
- 全数テストは不可能
- テストケース作成の心得
- 理由を述べる
  - 境界値分析
- 欠陥は局所的に発生する
QAチームは何をするの？
- QAチームはシステムテストレベルをみたい
- 単体テスト（開発）
- 統合テスト（開発）
- システムテスト（QA）
TestとCheckの違い
- Checking
- 意図通り動くか？
- Testing
- 負荷入力に耐えうるか？
- QAチームはテスト以外も行いたい
テストを行う理由をテストケース名にする
抽象度の高いものをテストケース名に
最新のテスト情報はJaSSTから
テストを実践的に学びたいならwacate

資料

デブサミ登壇当日！
私のセッションの注意事項を記事に書いていますので、聴講予定の方は読んでから来ると、さらに楽しめると思います！#devsumi https://t.co/PfhFuTf50k

— broccoli (@nihonbuson) February 13, 2020

少量データで軽量な機械学習の手法について

Quantum Core
秋吉信吾氏

リザーバコンピューティングを活用した次世代時系列処理基盤技術の開発・提供の導入支援
少ないデータでそれなりの精度を出すことが可能
深層学習でいうところの中間層をリザーバ層に
- 入力層-リザーバ層-出力層
- リザーバ層ならば重み更新不要（誤差逆伝播しない）
  - EchoStateProperyがミソ
    - 現在の入力は現在の内部状態に過去の入力や状態よりも大きな影響を及ぼす。
      つまりEchoStateProperyを持つということはEchoStateNetworkが最終的に安定状態になった時に初期状態に非依存である
複雑系力学を利用したもの
- 複雑系とはおよそ秩序とランダムの間の状態
ユースケース
- 個人に合わせる必要がある分野
- 環境に合わせる必要がある分野
- GPSはトンネル内の位置データを取得できない
  - 加速度センサで車体位置を推論する

個人的な補足
- リザーバコンピューティング
リザーバコンピューティングとは、レーザーの波長や波動く水面など、ダイナミクス(ノイズソース)を持つさまざまな物質を利用したコンピューティングのことで、これを活用したリカレントニューラルネットワーク（Recurrent Neural Network：RNN）が、最近新たな機械学習方式として注目されています。入力層、中間層（リザーバ層）、出力層（リードアウトニューロン層）の3層で構成される教師あり学習となります。
この方式では、ディープラーニングと違い、中間層を溜め池（Reservoir：リザーバ）にして計算を回すことで特徴抽出を行います。そのためディープラーニングで必要だった特徴抽出機能を学習により強化する必要がなく、学習時の中間層の重み更新が不要となる特徴を有しており、学習時の計算に必要なデータ量や計算力を著しく節約することができます。
なお、溜め池にはダイナミクス(ノイズソース)を持つものであれば様々なものが利用でき、現在はロボットやタコの身体をノイズソースとして計算する仕組みが探求されています。このように狭い意味では人工の神経回路を使って様々なノイズソースを用意し、そこから適宜情報を取り出して加算し計算する新しい人工の脳型コンピュータです。（引用：QuantumCoreがリザーバコンピューティングのコンパクト化に成功！業界初ラズパイ上での学習を実現した「EdgeQore」の提供を開始。手元のエッジデバイスでの活用が可能に。 | Ledge.ai）
- Echo State Propertyの参考
参考：ゼロから作るReservoir Computing - Qiita

以上

- カンファレンス, テクノロジー GCP, 機械学習, リザーバコンピューティング