「Cloud Native Meetup Tokyo #6」に参加してきました

  • Cloud Native Meetup Tokyo #6 KubeCon + CNCon Recapに参加してきました。

cloudnative.connpass.com

  • あまり詳しい領域ではないですが情報キャッチアップのために参加しました。
  • みなさん説明が論理だっていてわかりやすく雰囲気をつかむことができました。資料公開されているものは改めて確認したいと思います。
タイトル 発表者
Cortexの話をKubeConで聞きたかったっていう話 Shinya Uemura(@uesyn)
KubeCon + CNConに見るetcdの未来 Akihiro Ikezoe(@zoetro)
Monitoring Kubernetes Audit Log by Falco Makoto Hasegawa(@makocchi)
KubeCon + CloudNativeCon 2018 Seattle Recap ~Vitess~ Yutaka Ichikawa(@cyberblack28)
KubeCon + CNConでみたPrometheusの今後 Yoshi Shota(@yosshi_)

Cortexの話をKubeConで聞きたかったっていう話

  • Shinya Uemura(@uesyn)
  • KDDI & Creationline

KubeCon

  • Cortexのセッション一つ

Prometheus

  • メトリクス収集してローカルストレージに保存する
  • Long-term Storageではない

Cortex

  • Prometheusメトリクスのストレージ
  • マルチテナント型のモニタリングサービスを実現する

アーキテクチャ

  • 長期データS3やGCSに保存
  • chunkデータはDynamoDBやCassandraに保存

github.com

マルチテナント

  • リクエストヘッダ内のIDでテナント判断
  • テナントIDをもとにprometheusがふりわけ
  • 認証認可の機能はないのでIDを付与して送る実装を自前でする必要がある

kubernetes上で動かす

  • 「人類にははやすぎる」
  • まだリポジトリにreleaseブランチないしtagもついてない
  • 公式の入門ドキュメントまだない
  • フロント自前実装しないとマルチテナント使えない
    • nginxでやると楽だった

まとめ

  • cortex情報まだ少なめ

KubeCon + CNConに見るetcdの未来

  • Akihiro Ikezoe(@zoetro)
  • Cybozu

KubeCon

  • KubeConでetcd関連のセッション5つ

etcd

  • 分散キーバリューストア
  • HighAvailable
  • 強い整合性
  • Raftによる分散合意
  • k8sやVitessやCoreDNSなど多くの分散システムのバックエンドで使われてる

etcdの未来

  • CoreOS(Redhatに買収された)が作ってる
  • Container Linux
    • Fedora CoreOSが後継
    • 2020年いっぱいはメンテされる
  • rkt
    • Redhatとしては開発ストップ
  • etcdは?
    • CNCFのプロジェクトに採用
    • RedhatからCNCFに寄贈
    • CoreOSの外のメンテナ多いので体制に変化はなさそう

etcdの新機能

  • Raft Learner
  • etcd operator
  • Server Downgrade
  • Cluster init

Raft Learner

  • etcdはRaftという分散合意アルゴリズムを使ってる
  • クラスタからリーダーを選出
  • リーダーがメンバーにハートビート
    • リーダーは常に一つ
  • 問題点
    • データ同期中はI/O負荷高い
    • 同期中にネットワーク分断すると障害起きてしまう
  • Raft Learner
    • 同期中はLearnerという状態になる
    • その間は分散合意のメンバーとしてカウントされない

Cluster init

  • etcdの起動オプションいろいろ設定めんどくさい
  • 自動的にメンバーごとの名前やリッスンするアドレスなどを解決

etcdadm

  • etcdの運用大変
  • k8s上にetcdクラスタの運用
    • etcd operator
  • etcdadm
    • 実機やVMで動かしているときに使う
    • k8sに特化
    • etcdのクラスタの構築運用を自動化してくれる
      • メンバー追加/削除
      • バックアップ/リストア
      • アップグレード/ダウングレード
      • 証明書の管理

トラブルシューティング

  • etcdctl
  • auger
  • etcd-dump-logs

まとめ

  • etcdはk8sをはじめいろいろなところで使われている
  • CNCFに加わりメンテは安心して良さそう
  • 今後は運用者向けに嬉しい機能が出てきそう

Monitoring Kubernetes Audit Log by Falco

概要

  • Falco Deep Diveのセッション内容の紹介

Falcoとは

  • Container Native Runtime Security
  • コンテナ環境のセキュリティをモニタリング
  • CNCFのsandboxプロジェクト
  • モニタリングするだけ遮断とかはしない
  • 検出された時には手遅れだけど検出できる仕組みをつくることは重要

モニタリング

  • DKMS(Dynamic Kernel Module Support)によってmoduleがbuild/installされる
  • Ruleをyamlで書くことでモニタリングするイベントを定義

通知

  • 検知時にプログラム実行できる
  • webhookすればslack通知なんかもできる
  • Falco.yamlに設定

medium.com

k8sのaudit logをモニタリング

  • k8sのaudit log
    • k8s APIの呼び出しを時系列に記録
      • 怪しいリクエストの調査
      • 統計情報の収集
    • ファイル書き出し以外も対応(webhook等)
  • GKEではdefaultで有効になってる

k8sにfalcoを入れる

  • docker runでも動く
  • Helmのchartがあるのでそれが楽
  • falco operatorもある

KubeCon + CloudNativeCon 2018 Seattle Recap ~Vitess~

  • Yutaka Ichikawa(@cyberblack28)
  • APC

セッションサマリ

  • KubeCon
    • Vitess関連は3つくらい
    • 移行事例のセッションも
    • Intro
    • Deep Dive

Vitess

  • MySQLのshardingで水平にスケールするクラウドネイティブなDBクラスタ
  • goで出きててgRPCで通信
  • 事例
  • Sharding
    • 2つ以上のDBに分割してデータを格納
    • パフォーマンス向上
    • 垂直
      • テーブルごとに複数DBに格納
    • 水平
      • 1つのデーブルを複数Shardに分割して格納

HubSpotの事例

  • 10年間AWSを利用
    • 30日でGCP + k8s + Vitessに移行
  • なぜ?
    • シャーディングが魅力的だった
    • k8sとの親和性
    • OSS
  • 500データベースをアップデート

まとめ

  • youtubeの実績は強い
  • プロダクション事例増えつつある
  • k8sとの親和性の高さ
  • システムに合わせてチューニングは必要
  • Vitess as a Serviceなるものが生まれてきそう!?

KubeCon + CNConでみたPrometheusの今後

  • Yoshi Shota(@yosshi_)
  • NTT Communications

Prometheusの課題

  • 長期保管機能ない
    • 保管期間のばすと性能劣化
    • -> アダプターを使ってサードパーティストレージに保存
  • デフォルトで冗長構成がない

長期保管

  • Thanos
  • Cortex
  • M3

Thanos

  • 複数のPrometheusを横断して収集したい
  • 無制限に保管したい

Grafana Loki

  • ログの収集と可視化ツール
  • メトリクスだけではインシデントの全容の半分しかわからない
  • メトリクスとログの参照切り替えコストを最小限に抑える
  • まだAlpha版なのでproductionでは使っちゃだめ

Demo

https://grafana.com/video/loki_intro.mp4

「第1回AtomicDesignについて考える会」に参加してきました

  • 第1回AtomicDesignについて考える会に参加してきました。

thinkatomicdesign.connpass.com

  • AtomicDesignに関して様々な視点からの考えが聞けて学びが多かったです。
  • エンジニアとデザイナーあわさって、共通の考えを持って取り組むのがよいという意見が多かったです。
  • AtomicDesignにこだわりすぎずプロジェクトの中での共通認識のベースにしていくというのが良さそうと感じました。
  • パネルディスカッションでの質問の多さからもみんな悩んでるんだなってのを実感できました。
タイトル 発表者 ロール
コンポーネント指向から見るAtomic Design camcam_lemon (camcam_lemon) フロントエンドエンジニア
デザイナー・エンジニアのコンポーネント分割境界と、その理想郷 resessh (resessh) フロントエンドエンジニア
AtomicDesignを導入する理由と悩み sakito (mki_skt) フロントエンドエンジニア
手戻りが少ないアトミックデザインの導入 fujiken (kenshirof) デザイナー
Redaing The Atomic Workflow 腹筋ローラーの力を信じろ (8845musign) デザイナー
StorybookでAtomicDesignなコンポーネント管理してる話 masaya (msykd) フロントエンドエンジニア
サーバーサイドエンジニアがAtomicDesignを学んでみた remsleep_zzz (remsleep_zzz) サーバーサイドエンジニア
Atomic Design との上手な付き合い方 takanorip (takanori_oki_9) フロントエンドエンジニア

コンポーネント指向から見るAtomic Design

  • camcam_lemon (camcam_lemon)
  • フロントエンドエンジニア

AtomicDesign

  • 考えること多い
  • よく分かってないままアプリ単位で採用してるから
  • チームに合った設計を取り入れるのが正解ではないか

コンポーネント指向

  • UIパーツを部品として使う
  • 見た目と機能をカプセル化
  • 粒度が小さいほど再利用性が高まる

UIライブラリ

  • よく使うUIパーツを提供
  • AtomsかMoleculesを提供する
  • 再利用性に極振り
  • ロジックは入り込まない
  • UIライブラリのパーツに加えて再利用されないAtomsやMoleculesをアプリで作る

まとめ

  • 小さい単位で考えると悩みが減る
  • 再利用性に特化したUI設計に集中
  • 小さく始めて大きくスケール

デザイナー・エンジニアのコンポーネント分割境界と、その理想郷

  • resessh (resessh)
  • Retty
  • フロントエンドエンジニア

デザイナー視点

  • ユーザ行動をベースに考える
    • 画面を開いて関心のあるコンテンツを探す
    • コンテンツを理解
    • 手順を理解
    • アクションを実行する

エンジニア視点

  • コンテンツ内のレイアウトとコンテンツ外のレイアウト
    • 外 -> サイドバーとかヘッダーとか
  • データソースが決まったコンポーネントとそうでないコンポーネント
    • Storeにアクセスできるかどうか
    • Container Component / Presentational Component

コンポーネントの分類

  • Organisms
    • URLを持っていることが多い
    • アクションも付随していることが多い
    • 特定のデータソースに依存してもよい
  • Molecules
    • コンテンツが一つで完結しない
    • 特定のアクションを行うUI
    • 特定のデータソースに依存しない
  • Atoms
    • HTMLのタグに対応
  • 迷う時は
    • デザイナーとエンジニアが分類について対話できる環境があるとよい

AtomicDesignを導入する理由と悩み

  • sakito (mki_skt)
  • Yahoo
  • フロントエンドエンジニア

なぜ導入したか

  • デザイナーとエンジニアでコンポーネント分割の考え方が違う
  • 人数が多くて指標がなかった
    • 個人に依存
  • 導入して指標ができた

導入して抱えた悩み

  • PagesとOrganismsどの単位でReduxをConnectするか
    • プロジェクトの規模によりけり
  • AtomsなのかMoleculesなのか
  • エンジニアだけで導入してもダメ
    • デザイナーのアウトプットとの認識齟齬があってはいけない

まとめ

  • デザイナーとエンジニアで密にコミュニケーションをとる大事さは変わらない
  • チームにフィットした形で柔軟に返ることも大事

Redaing The Atomic Workflow

  • 腹筋ローラーの力を信じろ (8845musign)
  • デザイナー

The Atomic Workflow

  • 静的なカンプではなくブラウザに早く持っていくべき
  • Role
    • UX Designer
    • Visual Designer
    • Frontend Developer

UX Designer

  • コンテンツの並びを書いたもの
  • ページの構造と階層
  • レイアウトを作らずに議論できる

Visual Designer

  • The 20 second gut test
  • Style Tiles
    • 色とかフォントとかをまとめたもの
    • ビジュアルの洗練なしにレイアウトについて検討できる
  • 静的カンプ
    • 作らないわけではない
    • 全体像を描くのには有効
    • 段階が進んでからかく

Frontend Developer

  • デザイナーと近い席に座るべき
  • デザインプロセスのコアパート
  • 先行してマークアップしていくべき

ワークフロー

  • ブラウザでイテレーションすること
    • 一度ブラウザでデザインしたらブラウザにとどまり続けるべき
    • 意思決定を動くものでするべき
  • パターンベースで回す
    • 使い回せる

まとめ

  • ブラウザで生きた設計を
  • 常に全体を見て設計を
  • AtomicDesignの本質はステークホルダー全員との合意形成プロセス

手戻りが少ないアトミックデザインの導入

開発初期

  • 新規事業でAtomicDesignを導入
  • デザイナー一人
  • デザインデータが管理しきれなくなる
    • このデザインどっかで使ってたけどどこかにあるか分からん

導入前

期待

  • 管理が楽になる
  • 使い回しの適用がしやすくなる
  • スピードがあがる

導入してみて

導入するなら

  • カトナ期待はせずに
  • 定期的な整理整頓が待ってる
  • 整理で進捗が止まることを伝えておこう

導入中

  • 整理整頓そんなにうまくいかない
  • 整理整頓してる暇がなくて大きくなってしまう
  • コンポーネント化しすぎて無駄に時間かけすぎた
    • 適度にやることが大切

導入後

  • 曖昧さを許容すること
  • コンポーネントの粒度どうしてますか?
    • デザイナーとエンジニアで話し合ってる
    • 見てる視点が違うから理解し合うことが大切
  • 最初は特定の動作に特化した部品
    • 徐々に汎用的な部品に
  • ほとんどのデザインはすぐに消える

まとめ

  • 導入前:覚悟をもとう
  • 導入中:タイミングと量に注意
  • 導入後:曖昧さを許容しよう

StorybookでAtomicDesignなコンポーネント管理してる話

  • masaya (msykd)
  • モノオク株式会社
  • フロントエンドエンジニア

モノオク

  • モノの保管場所に困ってるユーザとスペースが余ってるホストをマッチング
  • React/Redux

Storybook

Storybookいいところ

Storybookつらいところ

  • メンテがめんどくさい
  • 開発に追われていると時間がない
  • コンポーネントマネージャーをおいた

まとめ

  • Storybook便利
  • 1,2人くらいのチームだとメンテコストのほうが高い
  • 他と比べてメンテの優先度下がりがち
  • 目的をもって運用方針を考えるべき

サーバーサイドエンジニアがAtomicDesignを学んでみた

  • remsleep_zzz (remsleep_zzz)
  • CyerBuzz / STARACT
  • サーバーサイドエンジニア

導入事例

  • うまくいった
    • デザイナーがReactかけたり
    • フロントエンドがAPI書いたり
    • といった環境だったから

サーバサイドから見ていいところ

  • 共通言語として使える
    • 学習コスト少し高い -> 習得後のブレが少ない
    • プロジェクトの途中から導入するるのはとても大変
  • 開発速度の向上
    • organismsとpagesだけにstateをもたせる
    • それよりも小さい粒度はstatelessなので爆速で作れる
    • Reduxみたいなところはフロントエンドエンジニアにまかせてコンポーネント単位で作り込める

まとめ

  • サーバサイドエンジニアからみてAtomicDesignのメリット
    • 共通言語としての役割
    • 粒度間違えなければ開発爆速

Atomic Design との上手な付き合い方

  • takanorip (takanori_oki_9)
  • フロントエンドエンジニア

思うこと

  • AtomicDesignに真面目すぎる
  • 設計の手助けのはずが難しくしている
  • 大雑把に付き合うことが大切
    • そこが本質ではない

意識すること

  • 最小単位(Atoms)を意識すること
    • それ以外はある程度全体見えてきてからでよい

なぜつらい

  • 考えることが多いから
  • ルールを整備することで考えることを減らせる
  • 再利用しないものとしてコンポーネントを作る
    • 通化しすぎると捨てづらくなる

責務を分ける

  • Pages/TemplatesとOrganisms以下の責務の分離

デザイナーを巻き込むこと

  • エンジニアだけでこういう話をするのは良くない
  • デザイナーにAtomicDesignの概念をフローに入れてもらう
  • 単位はデザイナーに決めてもらうのがいい

コンポーネントのデザイン

  • デザイン管理はFigmaが優秀
  • StoryBookもあるけどデザイナーが使うことも考えるとFigma

パネルディスカッション

  • コンポーネントガイドないとつらいですか?
    • レビュアーがつらい
    • PR出された時にそれもうありますって言えないとつらい
    • Storybookはディレクトリ構造をしっかり練ることが大切
  • コンポーネント命名規則
    • MoleculesはInputWithButtonのようにelement名をつけるようにするとわかりやすい
    • 使う時はSerchFormみたいな名前になるかもしれないけど

「Repro Tech : Frontend Reliability support NAVITIME」に参加してきました

  • Repro Tech : Frontend Reliability support NAVITIMEに参加してきました。

repro-tech.connpass.com

  • フロントエンドのreliabilityがテーマということでリアルな開発現場の苦労話を多く聞けました
  • Reproのイベントでしたが半分は豪華なゲストスピーカーということでバランス良かったです
タイトル 発表者
E2Eテストを継続するために brn
ReproのWeb SDK開発を支える技術 cheezenaan
続・Vue.jsによる大規模開発 kazupon
フロントエンド開発の土台としてのチーム作り 渡部啓太
クックパッドにおけるwebフロントエンドの改善 @hokaccha
フロントエンドと向き合う @treby

E2Eテストを継続するために

E2Eテスト

  • ユーザと同様に操作して機能を確認するテスト
  • Selenium等で自動で打鍵
  • メリット
    • ユーザが触る画面を直接テストするので確実性高い
  • デメリット
    • 遅い
    • アニメーションとかAPIアクセスとか遅い
    • 謎のエラーで失敗したり不安定
    • メンテナンス大変

E2Eのメンテ

  • CSSセレクタでDOMを選択
    • 変化が多いから大変
  • styled-components使ってるとE2E用にクラスつけないと
    • 自動生成のクラスが付与されるから
  • -> 放置されがち

デメリットの解決策

  • 遅い
    • アニメーション等はクラス名変えて停止してテストするとか
  • 不安定
    • リトライ入れて対応する
    • BrowserStack等外部環境を利用するとか

メンテナビリティ

  • メンテナビリティを実現するにはHTMLの構造に立ち入らないこと

VisualRegressionTest

  • スクショとって画像で比較
  • 前回と比較して変化がないかテストする
  • 変更ないのに差分検知してしまうことも
  • 失敗した理由がわからない
    • 結果しか見えないから
    • 目で見るようにする
    • 部分実行できるように作る

ブラウザ操作レイヤーの抽象化

  • ページ遷移とかはボタン押したりするのでHTMLの構造に依存してしまう
  • Graph Based PageObject
    • ユーザの操作単位でメソッドをきる
    • 部分的な実行もしやすくなった

まとめ

  • CIの整理やレビュー体制等のプロセスが大事
  • プロセスがアウトプットの品質を決める

QA

  • E2Eどれくらい時間かかってる?
    • CIで回してて30分くらい
    • mergeするタイミングで回してる
  • IE対応どうしたらいい?
    • BrowserStack使うか
    • Windowsサーバ立てるか
    • IEだけ手動でもいいと思う
  • SeleniumIDEどう?
    • その時通るテストしか作れないから手直し出てしまう
    • 雛形作るものとしては使えるかも

ReproのWeb SDK開発を支える技術

  • cheezenaanさん(Repro)

Web SDK開発

SDK

  • Software Development Kit
  • アプリ提供者向けの便利なライブラリ集

Web SDK

  • ブラウザ上でで動くSDK
  • ネイティブアプリと比べるとブラウザの分一層多い
    • ブラウザの種類・バージョンの差異がつらい

ReproのWeb SDKに求められること

  • 安心安全で信頼できるSDKを提供したい
  • なるべく多くのブラウザで動かしたい
  • プラットフォーム・バージョンどこまで対応する??
    • ビジネス要求と開発リソース次第

実際の取組み

  • ほぼ最新Chromeを基準にGraceful Degradation
  • 標準化されてないブラウザAPIは過信しない
  • 外部ライブラリへの依存を極力減らす
    • 使ってるライブラリ
  • ファイルサイズは小さく保つ
    • polyfill入れるくらいなら自分で書く
  • UnitTest手厚く
    • ブラウザ差異はE2Eで
    • 浅く広く作ってる
  • E2E

まとめ

  • ブラウザという壁から逃げずに向き合うことが大事
  • 依存少なくテスト手厚く

QA

  • WebSDKのE2Eどんなことやってる?
    • サンプルアプリに適用してテストしてる

続・Vue.jsによる大規模開発

  • kazuponさん

Vue

中大規模向け開発

  • 複数人で開発する
  • 生産性やメンテナンス性を考慮
  • 最初からフルスタックにはサポートしない
  • 公式にライブラリは提供してる

開発環境セットアップ

Vue CLI 3

  • プラグインベース
  • 構築拡張メンテが楽
  • VueCLIのレールから外れることはできない
  • ts対応
  • prettier
  • cypress

Vue CLI UI

  • ブラウザ上でVueCLIでできることは一通りできる
  • プロジェクト管理
  • GUIベースで設定
  • コマンドライン苦手な人に優しい

その他

  • VSCode + Vetur(VSCodeプラグイン)
  • eslint-plugin-vue
  • 通信
    • REST -> axios
    • GraphQL -> vue-apollo
  • 状態管理
    • VuexはTSだとつらい
  • E2Eテスト
    • cypressも使えるようになった
    • NightWatch

アプリ設計

コンポーネント設計

  • AtomicDesignに従いSFCを抽出
  • 秩序がたもてるなら無理にAtomicDesignに従わなくてもいいと思う

状態モデリングとデータフロー

  • UI使用から状態に落とし込む
  • モデルとAPI仕様はバックエンドと認識齟齬ないように工夫が必要
    • swaggerやOpenAPI Generator
    • Consumer Driven Contruct

ルーティング設計

  • スクロール位置喪失問題

アプリ実装

  • TS入れるといい
    • VueCLI3なら簡単に導入できる
  • TDD
    • テストはjestを推奨
      • スナップショットテストが便利
    • コンポーネント、データフロー、ルーティング全部TDDやる必要はない

デバッグ

  • Vue Devtools 5でより便利に

まとめ

  • VueCLI3で環境構築が楽になった

フロントエンド開発の土台としてのチーム作り

組織作り

  • すべての人間が同じ方向を向くことが大事

以前

  • お互い何をやってるか分かってなかった

やったこと

  • 情報の同期
    • ファイブフィンガー朝会
  • 情報の共有
    • 自分は何が得意
    • 何を期待する
    • 偏愛マップ
    • 自分の取説
    • スキルマップ
  • 目的の明確化
    • 我々はなぜここにいるのか
  • 毎週振り返り

今後

  • ビジネスサイドとの協働
  • 高負荷の解消

まとめ

  • チーム力は開発力の土台
  • チームと個人を向き合わせる
  • 振り返りでカイゼン

クックパッドにおけるwebフロントエンドの改善

クックパッド

  • Rails化して10周年
  • いろんな負債が積み重なってる

クックパッドのフロントエンド

  • Performance
  • Productivity

performance

techlife.cookpad.com

Productivity

  • 生産性をいかに上げるか

エラートラッキング

  • 全社的にsentry使ってる
  • ノイズがひどいので対応中

コードの整理

  • 現状
    • どこに何書いてあるか分からん
  • 対応
  • 既存コードを動かしながら対応するのは大変

モダン化

今後

  • 各チームが自由にライブラリ選定できる体制にしたい
  • Micro Frontendとか
    • 理想だけど難易度高そう

フロントエンドと向き合う

  • @trebyさん(Repro)

フロントエンド

  • フロントエンドはこわれる
    • ES2015でまともになってきた
  • 変化が激しい
  • テスト充実させたい
    • フロントエンドは簡単に壊れる
  • 3つの柱
    • 技術
    • チーム
    • 根性

「UIT#5 わたしたちにとってのVue.js」に参加してきました

  • UIT#5 わたしたちにとってのVue.jsに参加してきました。

uit.connpass.com

  • UITは#2から毎回参加していて4回目の参加でした(#4の参加レポート)
  • 今回はVueにフォーカスした勉強会で、事例を中心に技術選択の参考になるお話を聞けました。
タイトル 発表者
ゆるふわに既存Vue(Nuxt)プロジェクトをTypeScriptに移行してみた @Motonori Iwata
カメラを利用したアプリを作って約1,000人で遊んだ話 @KenjiroKubota
jQueryからVue.jsへリファクタしたPJの話 @tak
さくらのフロントエンド さくらの Vue.js @ravelll
Vue.jsは裏切らない @Yuji Yamaguchi
building better Vue components with storybook @julien

ゆるふわに既存Vue(Nuxt)プロジェクトをTypeScriptに移行してみた

  • @Motonori Iwata

TSへの移行

  • 社内ツールをTSに移行
  • Nuxt
  • Firebase
  • コンポーネント23個
  • 新規開発は停止
  • 4週間で移行完了

移行の順序

  • components -> utils/plugins/middleware -> store -> test
  • testが通ること確認しながら

設定

  • tsconfig.json
    • alloJSは一時的にtrueで
    • implicit anyは弾く

Linter

  • Xoを使ってる
  • https://github.com/xojs/xo
  • 型引数にしか使ってない変数がエラーになる
    • no-unused-varsをoffにして対応
  • 結構罠がありそうだからTSLintの方がいいかも

Components

  • vue-shims.d.tsをおく
  • vue-convertを使ってclassに変換

Test

  • jest使ってる
  • ts用のjestを追加

カメラを利用したアプリを作って約1,000人で遊んだ話

  • @KenjiroKubota(株式会社アイスタイル)

社内のイベントでアプリを作った

  • 表情を検出して笑顔度を測るアプリ

技術

WebRTC

  • WebRTC API
  • videoのリソース開放も忘れずに
  • requestAnimationFrame()
      • beforeDestroyで都度終了させないと重くなっていく

まとめ

  • Vueはググれば情報豊富
  • VueCLIのおかげでwebpackの苦労が不要
  • Firebaseすごい

jQueryからVue.jsへリファクタしたPJの話

  • @tak(LINE)

背景

  • 古い技術スタックのプロジェクトを担当した
  • どうやってリプレイスしていったのか

現行とゴール

  • LINE Webログイン
    • SSOを実現するページ
  • 現行ページ
  • 新ページ(順次公開予定)

なぜ置き換える必要あったか

  • 既存コード
    • 複雑に絡み合っていた
    • 担当者のスコープや責任が明確になっていなかった
      • CSS/HTMLの変更でもサーバサイドに手が入る
  • データやイベント発火フローの確立
  • 今後のリッチなUIへの対応
  • jQuery -> Vue
  • VueCLI3
  • バックエンドではエントリーポイントのルートコンポーネントだけ作成

リプレイス方法

  • $('xxx').on -> v-on
  • $('xxx').hide -> v-if
  • 等々

移行の例外

  • グローバルなメソッドを使った暗号化処理
  • 無理せずそのままにした
  • 外部ライブラリ的に使えるようにした

まとめ

  • データフローが明確になって運用コスト下がった(はず)
  • リファクタリングが危険な道は回避することも大事

さくらのフロントエンド さくらの Vue.js

さくらのフロントエンド

  • サーバ屋さんのフロントエンド
  • Vueがけっこう使われている
  • Vueの使い所
    • コントロールパネル
    • 問い合わせ/申し込みフォーム
    • 社内向けツール

なぜVue

  • デザイナと協業しやすそう
  • 公式からツールが出てる安心感
  • 日本語ドキュメント充実

事例

  • サービスコトロールパネルを刷新した
  • メンテしづらく属人化
    • Vueにリプレイス

技術スタック

  • Vue + Vue Router + Vuex
  • SPA, 非SSR, 非Nuxt

ディレクトリ構成

  • components
    • storeにはアクセスしない
  • pages
  • plugins
    • アプリ全体の挙動を変更する実装
    • Vue.useして使うもの
      • Vuelidateとか
  • utils

エラー検知

  • Sentry
    • 導入簡単
    • 401(セッション切れ), 422(APIのバリデーションエラー)以外を記録

テスト

  • コンポーネントのテストは複雑なとこだけ
  • データフロー以外のロジックを含むStoreのメソッド
  • jest使ってる

パッケージアップデート

  • yarn upgradeしてPR投げるCIを週一で
    • これはマイナーバージョンだけ
  • メジャーバージョンは手動

困りごと

  • デザイナーとの協業
  • コンポーネントの細かい挙動をSketchで伝えるのが大変
  • storybookを導入しようとしてる

Vue.jsは裏切らない

事例

従来

  • jQueru製の独自FW(2014末)
  • BabelifyでES6化
  • 秘伝のタレの積み重ねで完成度は高い
    • でも継続性に不安

やったこと

  • Browserify -> Webpack
  • Grunt -> Gulp/npm script
  • Mocha -> Jest

心がけたこと

  • 小さく移行する
    • 稼働してるプロジェクトだから
  • 画面ごと部品ごとに
  • さわるところだけとかリファクタリングだけとか
    • I/Fが変わらないことが大事
  • レガシーコードでもロジックは資産

良かったこと

  • バックエンドから転向組でもスムーズだった
  • template/script/styleのSFCわかりやすい
  • 人材が少ない中で誰でもそれなりに

難しかったこと

  • 自由にできすぎる
  • やらないことを決めるのも大事

まとめ

  • 利益をだしてるサービスの継続性は重要
  • Vueなら徐々に移行できた

building better Vue components with storybook

  • @julien(LINE)

Atomic Design

Vueに適用

  • 親から子はproperty
  • 子から親はイベント
  • propertyは一番シンプルに
  • 兄弟要素で相互に通信するのはだめ
    • 親を介してやりとりする

Storybook

  • 簡単にインスール/セットアップできる
  • whiteroom
    • Vueで作ったStorybook
    • Storybookの足りないところがあったから自作した
  • Vueで作ってるからライフサイクルを意識する必要がない
  • イベントも全部見れる
  • propertyとeventを同時に見ることができる

「Cookpad Tech Kitchen #20 クックパッドのマイクロサービスプラットフォーム現状」に参加してきました

  • Cookpad Tech Kitchen #20 クックパッドのマイクロサービスプラットフォーム現状に参加してきました

cookpad.connpass.com

  • Cookpadにおけサービスメッシュ、gRPC、ECSの導入事例を紹介してもらいました。
  • gRPCやEnvoy等気になっているサービスの話を聞くことができて参考になりました。
  • 講演だけでなくQAセッションもあり、採用する技術に対する深い話も聞くことができてとてもよかったです。
タイトル 発表者
クックパッドでのサービスメッシュについて 小野大器
gRPC in Cookpad 岩間雄太
Amazon ECS の安定運用 鈴木康平

クックパッドでのサービスメッシュについて

背景

  • 開発者200+
  • サービス100+
  • 色んな開発チームとSREチーム
    • 運用をSREチームから各チームへ移していきたい

課題

  • 昔は大きなモノリシック
    • 今は100近いアプリが相互に連携通信している
  • マイクロサービス内でインシデント起きた時の特定が大変
  • キャパシティプランニングも難しい
  • 何が起きているか見えるようにしたい

解決策

  • Expeditor
  • aws-xray
    • 分散トレーシング
  • ruby以外も各々作って改善を続けていかないといけない
  • ネットワークプロキシを挟んでそこでやらせればいいのではないか
    • サービスメッシュ
    • 2017年ころから

導入と運用

  • 2017年はじめに計画
  • 2017年終わりにMVP作った
  • 2018年から利用

Envoy

  • 当時使えるもので一番良かった
  • Istioはまだなかった
  • AmazonECSを使っていた
    • IstioはKubeが前提だから使えないかも

ゴール

  • 各アプリで管理するのではなく中央で制御したい
  • メトリクスはPrometheus
  • 運用コストを抑えたい

運用

結果

  • 一時的なエラー率上昇がタイムアウトリトライの設定で回避できるようになった
    • SREチームの負荷が下がった
  • 設定が中央に集まったのでレビューしやすくなった
  • Observability
    • 情報が可視化されるようになった

QA

  • 冪等性をどう担保している
    • GET/PUTは自動でリトライ
    • POSTとgRPCはリトライできると分かったるものはリトライ
      • デフォルトはリトライオフ
  • Istio使わない?
    • 今の構成で安定してるから今はこのまま
  • マイクロサービスを導入するタイミングは?
    • 組織が大きくなってきてコミュニケーションコストが大きくなってきたとき
    • 明らかペイするのは2000人とかの規模

gRPC in Cookpad

これまでのCookpadのサービス感通信

CookpadでのgRPC

gRPC

  • IDLとしてProtocol Buffersが使える
  • Protocol Bbufferでクライアント/サーバのコード生成
  • 多言語対応
  • HTTP2上で動作
  • Interceptorでログ、認証、エラー処理など

gRPCの運用

  • 基本的にhako上で
  • cookpad.comでも使ってる
  • Envoy経由でリクエストを受ける

サービス定義(ProtocolBuffer)の管理

  • 1つのリポジトリで管理
  • サービスごとにディレクトリを切ってる
  • ciでlintも入れてる
  • ドキュメントもciで自動生成
    • protoc-gen-doc

メトリクス

  • Envoyコンテナでメトリクス取る
  • Prometheusに入れてGrafanaで見る

rubyでgRPC

  • grpc gem
    • C, C++で作られたものをRubyの拡張として使用
    • マルチスレッド(シングルプロセス)
  • grpc-tool gemでクライアント/サーバのコード生成
  • 公式のgRPC実装を使用してる

今後

  • Envoyの機能を使ったかなりあリリース
  • 自作gRPCライブラリへの移行
  • grpc-gatewayの導入

QA

  • gRPCをRESTで叩くことはしてない
    • gRPC使う時はクライアント/サーバどちらもgRPCでやってる

Amazon ECS の安定運用

前提

  • ほとんどのアプリがECSで動いてる
  • hakoを使ってデプロイやバッチ起動
  • ECSインスタンス 40
  • ECSサービス 500
  • 1日あたりのRun Task 80000

コンテナインスタンスの管理

  • オンデマンドインスタンスはAutoScalingGroup
  • スポットインスタンスはSpotFleet
  • オンデマンド:スポット=1:4
  • Fargate
    • 一部使ってるけど基本自前管理
      • 自前のほうが安いから
      • 起動が遅いし起動時間が安定しないから
    • 使うケース
      • ECSクラスタのオートスケールするジョブ
      • 特別大きいCPUリソースを使うジョブ

オンデマンドインスタンス

  • 自前でオートスケール
  • AutoScalingGroup

スポットインスタンス

  • オートスケールは自前
  • SpotFleet

オートスケーリング

スケールアウト
  • CloudWatchの値をチェックして閾値を超えたらスケールアウト
  • 各サービスの値をチェックしてスケールアウト
  • hako oneshotがリソース不足で失敗したときにSQSで通知を受け取ってスケールアウト
スケールイン
  • CloudWatchの値をチェックして閾値を下回ったらスケールイン

ログ

  • fluentd経由でS3に保存
  • Athenaで簡易検索できるようにしてる

CloudWatch Logs

  • 量が多すぎてピークタイムではリアルタイムにに入りきらない
  • スケーラブルで安価なS3を使うことに

ログ配送

  • 各コンテナからfluentdの集約ノードへ転送
    • 集約ノードには大量のログが来ることになる
  • 集約ノードのfluentdが1分毎にログをS3へ

ログ検索

  • Athenaで検索できるようにGlueでカタログを日時更新

モニタリング

  • CloudWatchにサービス単位のメトリクスはある
    • タスク単位やコンテナ単位はない
  • アプリ開発者はアプリコンテナのメトリクスだけ見たい
  • cAdvisorでメトリクスを取得しPrometheus送りGrafanaで可視化

QA

  • なぜECS?なぜkubeでない?EKSは?
    • 運用する人が多くないからできるだけマネージドがいい
    • EKSがECSくらい使いやすくなったら使うかも
      • 今はECSほどマネージドではない
      • 今すぐ移行するというほどではない