Developers Summit 2019 KANSAI
カンファレンスレポートです
伊勢の老舗食堂「えびや」がAIフル活用のTech企業「EBILAB」に変貌。〜IT業界のおかしな常識を全否定！！超異能があつまるチームによる価値創造開発手法に迫る〜
常盤木 龍治 [EBILAB]
- 飲食店をデータ企業に
- データに基づいてメニューの看板を時間帯で変更
- スタッフ全員がスラック（60歳もスラック）
- fitbitでデータ管理
- スタッフの心拍数をとっている。その健康状態からアサインを考えてたりする。
- ベンダーを利用しない。AIもIoTもDBも最新技術に臆せず勉強。スタッフそれぞれが独学。
- AzurePlatformを利用。ホールスタッフからデータサイエンティストになった人もいる→サティアナデラに注目される
- 接客したいけど、組織に染まりたくないひとが飲食店にあつまる
- デザイナーにデザインさせない。現場の人にデザインさせる
- 食材の廃棄ロス72.8%削減
- 食べログ2.8から3.5に
- 食べログスコアと売り上げ相関 : 0.1で1000万、1上がると3000万
- 無駄なPPT、エクセル、会議の排除
- 朝令暮改、新しいものを許容。
- 業務はだれか一人だけがわかるという状況は排除
- そのひとがいなくなっても問題ない体制を確立
- 本質的に重要でないタスクの取りこぼしを責めない
- Asana
- slackのジレンマからの解放
- Azure DevOpsからGitHubへ
- Azure DevOpsを強制したところ、エンジニアの士気がさがった
- 「ときわぎくらうど」で検索
コンテナをシンプルに使おう〜Cloud Runのすすめ〜
篠原 一徳 [GoogleCloudJapan]
コンテナ→Kubernetesがデファクト
- k8sはインフラをうまく抽象化している
開発者はコードを描きたい
- インフラ側を触りたくない
もっと簡単にするならサーバレス
- Cloud RunはコンテナイメージをGCPへホストする
Kantive
Kubernetesの上にサーバレス環境を実現するOSS
従来はベンダーの独自実装によるロックインがあったが、
Cloud Runならコンテナを利用するのでその心配もない
Cloud Run
- Knative準拠
- 高速に0toNスケール
- コールドスタートを極力排除
- 管理するサーバなし、コードに集中
- 高いポータビリティ
- OSS利用による恩恵
- https準拠、SSLサーバ証明書も払い出される
- カスタムドメインでドメイン持ち込みも可能
- マシンスペックに制限はある
Cloud Runのスペック
- CPU
- デフォルトv1CPU
- 変更不可
- memory
- 最大2G
Googleにおける標準アーキテクチャの考え方
中井 悦司 [GoogleCloudJapan] Solution Architect
- 標準化は難しい
- 合理思考に基づいた分散設計をベースに
GCPのコンセプト
- もともとGoogleの社内のプライベートクラウドをパブリックにしたもの
- Datacenter as a computer : ソフトウェアエンジニアはどこのサーバで動いているかを意識しない
- Borg(サーバインフラ)
- ようはk8s。k8sプロジェクトの元祖
- 最初はBorgをそのまま公開しようという話もあったが、Google向きにチューンされすぎていたので、スクラッチで実装したものがKubernetes
- Large-scale cluster management at Google with Borg
https://ai.google/research/pubs/pub43438
グローバルな専用回線
- 大陸（リージョン）またぎでも通信が安定：インターネットではなく、専用回線を利用しているから
共通ミドルウェアサービス
- 分散基盤を利用
- スケーリングが前提として考えられている
Bigtable: 低レイテンシを追求したNoSQL
- 分散型のデータストレージ
- NoSQLなので、クエリはシンプルなものに限られる
- Gmailの一部データがBigtableにストアされている
Googleの技術は論文として公開されている
https://ai.google/research/
- Googleを支えるテクノロジー
https://www.school.ctc-g.co.jp/columns/nakai2/nakai201.html
Global Load Balancer: シングルIPで複数リージョンにロードバランス
- ユーザからみてもっとも近いリージョンにルーティングする技術
- 利用例：サーチエンジン
- パケットのルーティングに利用
- 実はサーチエンジンのLBとGCPのLBを共有している
- LANケーブルが不要
Cloud Dataflow: リアルタイムストリーミング
- 分散データ処理系のサービス
- 多段 map reduce処理をバッチでもリアルタイムでもどちらでも利用可能
- MillWheel Googleのサーチエンジンに投げられるクエリをリアルタイム処理する
- MillWheel: Fault-Tolerant Stream Processing at Internet Scale
https://ai.google/research/pubs/pub41378
Context-aware access: ユーザのIDとコンテキストに基づいてアプリとインフラストラクチャへのアクセスを管理
https://cloud.google.com/context-aware-access/?hl=ja
- BeyondCorp（Googleの社内ネットワーク）
- Google社内イントラ（実はインターネットに公開されている）
- 物理的にはインターネットにさらされているが、端末のエージェント、指キーで認証しないとアクセスできない
- Googleは社内イントラにVPNアクセスをしない
- 背後には0トラストネットワークの思想がある
- インターネットは危険だが、FW内のオフィスネットワークは安全
- でも、FWを破られたら危険 → FWではなく、その間に様々なセキュリティを構えている
Googleにおける標準化とは
標準化 = ベストプラクティスの追求
- ソフトウェアエンジニアは非常に合理的な考え方をする
- 経験があるから、その技術を利用するという主張は通らない
Cloud Spanner
分散RDB
- もともとは特定プロジェクトのものだった
- やはりトランザクション、joinをしたいという要望がうまれる
- Jeff Deanがその特定プロジェクトのために考案(https://qiita.com/umegaya/items/ef69461d6f4967d5c623#fn3)
- プロジェクト個別にSpannerを用意するのは非合理的
- 最初から分散、共有できるものとして設計
ベストプラクティスを追求した一例： Googleデータセンタ内のスイッチの変遷
- Google自作している: サーバ、L2スイッチ
- 1P/Bpsを捌けるスイッチ(ネットワークベンダから購入すると高価)
- なぜ自作したか？
- ネットワークトラフィック量の増加がベンダが提供するスイッチではさばききれなくなるという予測がたったため
- 当初はネットワークベンダほどのクオリティのものは作れなかったが、徐々に質が向上
ホテル・旅館運営企業が毎週リリースするDevOpsサイクルを作るまでの道のり
藤井 崇介 [星野リゾート]
自己紹介
- 11年開発会社で勤務後、星野リゾートへ
- もともとJava
星野リゾートについて
- 創業105年
- 情シス 30名
- もともと接客をやっていたstaffがエンジニアに
システムについて
- 独自システムが多い
- 競合他社との差別化のために独自システムが必要
- 自社HP
- 外部サービスを利用しない。
- 2016年、情報システム部はわずか5名
- 内製する余力がなく、外部ベンダ依存
- 2018年に星野リゾートに入社
- 内製化のスタートラインに立つ
- 社内の問題点
・スケジュールの合意形成フローがない(ステークホルダーが多い)
・ステークホルダーが多い弊害：タスクの優先順位が不明確に - 合意形成のフローの整理
- 工数をポイント制に変更
- QCDのコントロール
- Q: Quality
- C: Cost
- D: Delivaly
- 改善当初の状況
- 社内では好評
- ふと気がつく違和感:スクラム導入できないか
スクラム導入
- 理由
- コミュニケーション機会を増やす
- フォロー体制の強化
- 開発効率
- 取り入れたツール
- Backlog
- trello
- Jenkins
- 学んだこと
- 機能横断でツールをつくる：チームを分断するとボトルネックができる
- スウォーミング: ひとつの課題にチームでとりくむ
- メリット
- 小さな成果物を早く提供可能
- 自分ができなかった作業のやり方がわかる
- 成果物が個人に依存しない
- 改善にも時間をつかう
- Docker導入（プラットフォーム依存を排除）
- プルリクの承認フロー
- スクラムを導入した結果
- 毎週リリース、継続的なDevOpsサイクル
- 改善がすすめば内製化がすすむ
- 会社としてエンジニアをふやそうという方針に
- 会社のビジネス展開を支えるためには、エンジニアが重要
まとめ
- 外部に依存した体制から、内製化に方向転換することで、改善できる
- 改善するためには、組織文化の支えが重要
- 内製化するからこそ、スクラムを取り入れる
- エンジニアが成果を出すと、経営の方向も変わる
CI/CDを使い倒して数段上のソフトウェア開発をしよう！
金 洋国 [CircleCI]
CI/CDについて
https://codezine.jp/article/detail/11083
CI：継続的インテグレーション
なぜテストを書くべきか？
- なんども同じ手順を繰り返さなければならあに
- 人間は間違う
ただテストを書くだけでは不十分
- テストがあるけど実行わすれた
- テストが環境依存
- 昔書いたテストが壊れてうごかない
常にテストを回す
- テストし忘れを防ぐ
テストが壊れてしまう
- 壊れたテストを検知
- 直さないとマージできない
- 使われない自動化は壊れていく
- 壊れたら直すを繰り返さないと、テストは陳腐化していく
テスト結果が環境に依存する
- CIを唯一のテスト環境にする
- 毎回同じテスト環境が構築される（Docker）
- まっさらな環境で常に実行
- いつ実行しても同じ結果
CIの目的
- テストの新陳代謝を高めて信頼性をあげる
CIを導入できない理由
テストがない
- テスト文化の布教にはコストと時間がかかる
CI/CDツールをつかう
さまざまなタスクを自動化する
テスト以外に
- 構文チェック等
可視化する
- ステータスバッジ
マージブロック有効化
- mergeできる条件をブランチごとに設定
テストの追加
- 少しずつテストを追加していく
メンテナンス
- CI/CDツールのメンテナンスは大変
- 通常専任エンジニアが必要
- CircleCIのようなクラウド型がおすすめ(インフラの世話が不要)
CIまとめ
- テストがなくてもCIははじめられる
CD継続的デリバリー
継続的デリバリーと継続的デプロイメントはちがう
継続的デリバリー
- リリース作業に人間の意思が介在する
継続的デプロイメント
- リリースに人の意思が介在しない
フィードバックループ
- 細かい単位でリリース
- フィードバックを早めに
- 改善を得る
CDがないと、ループがまわらない
No CD, No Feedback
Why Not CD
- そもそもシステムがCDに向いていない
- 時間をかけてアップデートするしかない
CD導入の銀の弾丸はない
Circle CIでの事例
- 常に200台以上のビルドマシンからなるフリート
- ChatOps(hubot:人力)デプロイ
1年かけて以下を実施 - Docker,Kubernetesの導入
- マイクロサービス化
新システムにはまずCI/CDを導入
- レガシーなシステムへの導入はあきらめることも
まとめ
- CDがまわるとfeedbackが回る
CDのその先
迅速なロールバック
git revert
本番環境でテスト
- テスト環境でできるテストはかなり限られている
- 本番でバグをふむ確率が高くなる
- Dockerのverが違う。GitHubのAPI制限にひっかかる
つまり、リリースしてみないとわからない
デプロイとリリースは違う
- デプロイ
本番環境に配置すること - リリース
本番トラフィックを受けること
高度なリリース手法
- カナリーリリース
- ブルーグリーンリリース
CDをつかいこなすと、、、
プログラミングに対する圧倒的な心理的な安全性が得られる
CI/CDはどこへ向かうのか？
CI/CDの歴史は自動化の歴史
今、手動でやっていることが自動化されるだろう
以上