miusukeeee - Tumblr blog

miusukeeee · 5 years ago

Text

前提

このエントリは社内のメンバー向けに書いたものを成形したものです

文脈や前段で説明すべきことが飛んでたりするかもしれないです

興味があれば注釈加えるので指摘ください

このエントリの目的

会社で書いたポエムをソトに出して世界とチューニングをすること

置換

施策を開始するときのキックオフミーティングについてのエントリです

通常のミーティングとは人を集める重み付けなど異なることがあります

置き換える際には色々少し弱めにしてみてください

キックオフミーティングを開く目的

今僕ら(=ユーザー/クライアント)が抱えている課題・問題に対して、チームとしてどのような危機感で反応をして、どのような方向性で、どのような対応をするべきかということへの共通認識をもつこと

共通認識が取れている場合

情報伝達でいいなら

チケットを回す

slackでフランクに連絡する

承認が欲しいなら

回覧板を回す

レビューをしてほしいなら

チケットなりgithubなりZeplinなりで賄う

今置かれている状態とそれに対する反応を共有するためにキックオフが開かれるべきである

もし目的が異なるのならキックオフミーティングという形で会を開くのをやめましょう (ただ、適切な共通認識がないと上記のはあまり意味をなさないので他の形ではやっとこうね)

キックオフミーティングが開かれるタイミング

複数のタイミングでキックオフミーティングが開かれることがある

1 ある課題に対し、どういう方向性でいくかを決めたい時

2 ある課題に対し、「こういう方向性の施策でいくぞ」と宣言する時

3 施策が決まり、プロジェクトを開始する時

4 プロジェクト内でフェーズが大きく変化した時

開かられる時準備されているべきこと

1.「ある課題に対し、どういう方向性でいくかを決めたい時」の場合

課題が存在する根拠となるデータ

数字、ユーザー/クライアント意見、データ

ex) PVが減った、こういう要望があった、データの不整合が起きた、など

課題が解決されないとどうなるかの仮説

or 課題が解決されるとどうなるかの仮説

ex) 「1人あたり購買回数が少なくなっている、リテンションが弱いということはどんどんCVが減っていくぞ」みたいな時

2.「ある課題に対し、「こういう方向性の施策でいくぞ」と宣言する」の場合

課題の根本的原因の調査結果とその解決方針案

数字、データ

解決されるときのシミュレーション

解決方針の素案と、仮説ベースでの効果予測

ex) 「一度購買したユーザーが完全に離脱するタイミングはメルマガの送付タイミングだ！メルマガをやめよう！いや違う辞めさせないメルマガを送ろう！！うーん後者だ！」の時

3.「施策が決まり、プロジェクトを開始する時」の場合

施策の具体的な要件、成功要因

ユーザーの欲求と課題とそれを満たすストーリー

それに必要なもの

機能要件

画面や文面のラフ

それに不要なもの

作らないもの

やらないこと

やりたいがスコープが大きくなるもの

ex) メール・そこからのLPの改善をする際に、キャンペーンも同時進行するなど

効果検証に必要な数字/こと

施策が上手くいったかどうかを判断するためだけではない

エンジニアがテストコードを書くのと同様に、はじめに道筋を立てておき途中で逸れないようにするため

効果検証に見直しが必要になった場合は施策の見直しを強く検討する

ex) 「休眠したユーザーに再度購買してもらうためにパーソナライズしたおすすめ商品のメールを送ろう、購買への距離を縮めるためにメールから遷移した先におすすめ商品一覧の画面を作る」の時

4「プロジェクト内でフェーズが大きく変化した時」の場合

3.「施策が決まり、プロジェクトを開始する時」に循環していくので3と同じ

これらが用意されていないor適切なタイミングで行われないと

施策のレビューで方針に食い違いがあり全部やり直しになる

方針は決めたが実際の問題と乖離が生まれサービスの改悪となる

課題からいきなり施策に飛んでしまうため、結果的に根本解決がなされない

と、大変

さらに

キックオフミーティング中に上記の状態になるのを見越せてしまった場合、話のスコープがずれ、ゴールを見失い、ただ議論をしているだけでどこにも着地しないミーティングとなる

さらにさらに

着地しないならいいが、無理やり着地しようとしたり無駄な議論の中で生まれた課題(っぽいもの)を次回の議題に加えたりすると元々の課題を解決しない施策が承認を得ることになり、誰も幸せになれないサービス開発の時間を過ごすことになる

fin.

キックオフミーティングの進め方

参加者全員が意識するべきこと

いま1~3のどのフェーズなのか

キックオフされたこのプロジェクトのゴールはなんなのか

プロジェクトが達成されるときまでにいつどのようなチェックポイントがあるのか

決定済みのものはどこに記録されるのか

いま1~3のどのフェーズなのか

上記を確認し、準備ができていないものがあれば、その前のフェーズから開始する

フェーズ1の準備ができていない場合は課題設定が曖昧・不足をしている。その際はサービス設計者(事業責任者・PdMなど)と認識をあわせるとうまく進む

キックオフされたこのプロジェクトのゴールはなんなのか

基本的には1~3の次のフェーズに行くのがゴールとするのが美しい

源氏的にはリリースまでを一気通貫してゴールと置くことが多く効率的

リリースがゴールなのか？

ゴールは基本的に効果検証(で課題が解消が確認された時)とするべき

いくら数字・ユーザーヒアリングを重ねても現実に届かないことはある

更に改善・改修を行う(or 元に戻る)かを判断することが必須

そのためフェーズ3の時点で効果検証までを計画することが重要

フェーズ2以降の場合ゴールまでの道のりを、一度で至るのかどうかの共通認識を必ず取る

試験的なのか、暫定的なのか、理想的なのか

ゴールまでの道のりの補足

試験的なのか、暫定的なのか、理想的なのか

一度で100点を目指すのか、赤点を合格点にするのか、120点になる奇策を世にあててみるのか

スケジュールや利用者の範囲、実装方針などが大きく変わる

なにより効果検証後にどうプロジェクト進行が変わる

「前変えたばっかりなのにまたやるの？」

「良かったから影響範囲を広げましょう」などの方針が変わる

試験的な場合は次に何を見越しているのか

何があったら合格なのか、再試験なのかの定義

その試験は何に活かせるのか

暫定処置の場合はなんの判断を持っていつstop/stayを決めるのか

理想を夢想している場合はどこを目指すのか

そこに至らなかった場合の改善はやるのか

いつどのようにやるか

ここまでの認識が揃うとプロジェクト後に混乱が生まれることが少なくなるチーム内で言葉の定義を揃えておくのも有用だと思われる

プロジェクトが達成されるときまでにいつどのようなチェックポイントがあるのか

前述の通りフェーズ細かく区切ることはあまり多くない

長い道のりを担当者(達)だけで走るとブレることが多々ある

タスクの切れ目などわかりやすいタイミングで共有が必要

調査・分析・施策立案・要件定義・API設計など

チェックポイントでのチェックについて

確認者は出来る限り小さく選定する

確認者はキックオフミーティングに参加した全員である必要はない

完了と開始の場に他者を介在させるのが目的

課題を満たせているか、適切なゴールが設定されているかを確認する

必ずしもミーティングである必要はない

チケットにメモするのではなく一連の議事録のようなものだと時系列を追いやすい

一つの物語として巻物スタイルで保存する

リンクを貼るだけでいい

粒度が小さく不要であれど記録と共有は続ける

slackで1文投げるだけでもいい

キックオフや前チェックポイントでの議事録で前提は揃えられる状態を保つことが大事

チェックポイントは人から人へバトンを渡すタイミングでもある事が多く認識齟齬が生まれやすい

決定済みのものはどこに記録されるのか

dropboxのどことかesaのどことかredmineのどのチケットとかgithubのissueとか自由にすればいい

巻物からリンクを貼る

これが共有されていれば記憶違いが無くなる

プロジェクト途中でヘルプを頼むことも出来る

似たような施策をするときの参考資料にもなる

チームに積もる資産となる

キックオフミーティングの参加者がやること

これらを全てキックオフミーティングの主催者が準備するわけではない

主催者は大枠のアジェンダを作成しそのアジェンダを参加者候補にレビューしてもらう

アジェンダの枠の過不足のレビューができる

主催者の経験の有無でミーティングの質が変わらなくなる

議論したい議題があればそれを書いてもらう

アドリブでの質疑応答や議論は声が大きい人(関わりが深い人)の意見が通りやすくなってしまう

参加者がどこに興味や意識を置いているかで参加者の過不足が事前に判断できる

議題案の優先順位を決め、時間内に収まるように取捨選択をする

「話すこと」を決めるのも重要だが「話さないこと」を決めるのはもっと重要

「話さないこと」を話す場は別途記載者を中心に解決する

主催者へ

参加者の数は最大の数が最小の数である

一部のステークホルダーだけで行うと実作業で認識の齟齬が発生する

プレイヤー層との認識の共有が重要

状況に拠るが関係する各セクション1人は必ず必要になる

開発や広告など関わらないと判別できる場合は必須ではない

状況の共有はしておくと不慮の事故を避けられる

全員へ参加するための準備

キックオフのスタートとゴールだけは理解しておくこと

読み合わせは行うが、理解度を揃えるための時間は取れないため必須

想定される質問事項は前もって提示しておく

主催者/参加者共にその場で質問すると回答の質が下がる可能性が高い

アドリブが悪ではないので質問は積極的に行っていいことは伝える

最低限、前提知識を思い出しておく

巻物のタイトルをさらう程度で大きく変わるのでそれを行う

最後に

これは素案の素案でまだ運用した実績がないものですチームで経験というエビデンスを重ねて当資料を完成させられたらいいなと思います

さよなら、さよなら、さよなら

0 notes

miusukeeee · 7 years ago

Text

Devsummit2018

過去ログ

Dev Summit運用 8+8 * N列 16列ぐらい？ B 見える範囲だけで1部屋に5人ぐらいいる受付、音響、途中参加者の誘導*2ぐらい

撮影OKなのかNGなのかを表示する立て札みたいのあるといい

ランチセッションはガンガン入って食べさせて、食べてから聞く方がいい、音もあるし

参加者webアンケートに答えると、資料がもらえるってやりやすくない？？

運用について無停止でtokyo regionに持ってくる方法考えるデータとキャッシュがつらそうなのでslaveをtokyoにおいて、切替時と同時にマスターに昇格、ただ台湾もマスター気分いや、死ぬな、無理だ Scaleユニット、podの単位を��確にして、scaleさせる計画を練る今回のタイミングで、Nodeをscalableにしなくちゃいけないそして、その後にk8sでservice-deploymentでscalableに sakura-deploymentも nginxもかなりあ環境ちゃんと作りたい

memcachedを2こ使ってるけど、死んだら死ぬので、なんらかのなにかに移行する

そのうち、東京大阪両方に散らしたいよね

とりあえずSRE本配ろうか

B2 全アーキテクトとマイクロソフトの NoOpsのやつ

運用は設計をみすえて、、みたいな話

好きなものを好きな時にローンチしたい vs 一旦動いたシステムは変更したくない SRE本

開発と運用をわけるとか、そういうの、えぐいいまのMDUは運用と開発を同時にやってる→DevOpsだよね

いや、NoOps

Ops　10年戦争

運用保守はITILのリファレンスにもあるとおりレビューとかアホみたいにあるリードタイム長い、物理的限界→PDCAがふぁっきん長期

「変更が一番のバグの原因」→書類とか多い、仕様が凍結されるでもハードウェアは死ぬから運用は大変

2008年からの仮想化がハードとソフトの依存関係を切り離せるし、クラウドまで行くと運用しなくていいぜ

landing.google.com/sre

昔堅牢さ＝信頼性 AWS時代壊れる前提でオペレーションしようぜ NoOps システムに自立運用能力をもたせる壊れた前提で設計、壊れた後に治す準備までを設計しようぜ

回復性設計 azure/architecture/resiliency いかに止めないかミドルウェアに回復性を実装するのは意味わからないぐらい辛い platformにあってくれクラウドネイティブのものがいい -> Serverless (lambdaとか)

NoOps in Azure App Service

serviceについて考える

今の構成だとingressがNodeの中にあるから、リージョン跨いでサービス作ることが出来ない (例えば大阪におくとか)

地理的冗長化もかんがえる

self Healingは healthcheck死ぬとk8sがやってくれる

in-flight renewingはできない

Adaptive Scale GKEのオートスケール k8sのオートスケール、ただDB,cacheあたりはオートスケールできない正直ここだけはAWS おーろらにしたい

DB載せ替えしたいぞ

河野さん？

superriver 帝国兵

Azure console

App restartみたいなのめっちゃ良さそ�� ログ見にいかなきゃ行けないのも見えるし、そもそも気づかないうちに起こっててハッピー

アプリケーションにも回復性をもたせたい

小さな龍後のステートレス設計非同期処理前提冪等性 -> serverlessの考え方 DevOps -> DevDevDevへ - ジョブに、キューに、ジョブを並列実行し、結果を書き込め - scoreの考え方をこれでやろう - 大量バッチの。。。みたいのがサンプルとかハンズオンにあるから見てみよう - ここかっこいい、真似したい

github.com/noops-jp

noops.connpass.com

BL もしSierのエンジニアがSRE本を読んだらエーピーコミュニケーションズあんどうともき APC pythonでAPI叩く Ansivle, Terraformに手を出したい

絶対的な力関係で無茶振り… 手順書&ダブルチェック… 依頼…非効率…

運用までシステム化したい心理的安全性を高めて生産性を高めよう

ソフトウェアエンジニアリング+サーバーネットワークインフラエンジニアやなおれじゃん！

リスク受容して信頼せ100%を目指さない SLIを本にSLOを決める、これはSLAじゃないぞ人じゃなくてデータに依る判断で標準化するエラーバジェット = 100% - SLO 開発と運用がエラーバジェットを共有

ﾄｲﾙ

手作業の繰り返しのことサービスが成長するとそうなる運用を業務の50%以下にする大きな自社サービスを展開している&高い技術を…

リスクの需要

100%という意識

SLA > SLO (1/100ならいーじゃんとはならず, ただただ0にしろと言われる)

指標となるデータが見つからない…

自動化が可能な作業かどうかが技術力に左右されるうんこ

関係者が増えるとやっばい

なんとか取り入れるやりやすい手法

50%ルール

価値の高いことをするため、時間を確保する戦略(と言い換えることで説得しやすい) 運用が100%+だしつらい運用改善すら出来ないトイルの対処 - 湯やる必要ないものは捨てる - 優先順位をつける - アウトソーシング - 代行してもらったら早かったり正確だったりする…？ - 順序のいれかえ - フローの順序が運用設計で作られるけど - ほんとにこれがただしい？を常に考える - 特殊性の排除 - イレギュラー対応、例外的な処理は非効率だし事故起きやすいし属人性高いし - 汎用的な手順で処理できるように仕様 - そうすると自動化(コードに落とす)ときにもめっちゃいいよ - 自動化 - 上記でふるいをかけたものを自動化することで正しい判断ができる - 自動化するのが目的になっちゃったり - こーどがくっちゃくちゃになったり

壁

教育学習コスト、工数、理解、、、たいへん。。。。変えるリスクをあげるのは簡単、変わらないリスクを考える必要がある

変わるべき vs 変わらないべきどっちも過大評価するないきなり議論をするな - プロトタイピング動く所をみせてメリットアピールしよう - めちゃくちゃスモールスタートして、知見と実績つもう - 人を巻き込もう

その後…

時間を確保したら - さらなる改善をする - 変化は継続しないと意味がない - そのためにスキルアップだし、それが出来てスキルアップ - トレンドおっかけようぜ

xxxx

当たり前になってる業務に新しい気付きいいものもわるいものもでてくる異なる意見もあつめようぜ、突破口になる Googleのをそのままはできない

serviceでは…

MMDUと共有することで、100なんか無理だろ!と壊れた理由言えよ!の対立を無くす正直マジでだるいから CSなんかがどんどん増えていくのはわかりきっている、自動化できるものはするお問い合わせフォームを無くすの良くない？変わらないリスクをめちゃくちゃ考える必要がある競合の新しいものが生まれたらどうする？メンバー腐る SRE読書会

加速するフロントエンド PWA 立ち見エグいめっちゃやせたな inside frontend で話したものを見てみたい mizchi　さーん node.js Rtech, freee

Reactの人ではないぞ [今]のパフォチューの常識でまっとうに作るとこんなに早いぞ serviceのプロトタイピングで作ってみようかな r.nikkei.com nikkei-inside-frontend 宍戸さんえぐい

PWAについて

本質モダンなブラウザを使うユーザーにはよりyい体験をという方向性 - serviceWorerを使ったモバイルアプリに追いつくぞ ServiceWorkerが実装されているか否か、レガシー→ IE,Safari can i use 毎回忘れるから覚える

SWについて

バックグラウンドで動くローカルプロキシあらゆるレスポンスを書き換え可能 httpsじゃないと動かない

従来のリクエスト＆レスポンスモデルの常識が通用しないぞ！！！死ぬぞ！！！すべてのものをとれんぞ UI ThreadとServerの間にServiceWorkerがいるモデル(ローカルプロキシ) リクエストから15secぐらいでsleep タブが死んでてもサーバーからのpushイベントも受け取れる、おもしろ

出来ないこと

常駐プロセスができない、 15-30秒ぐらい絵あれ Web Budget API　−メモリ使用量も制限 (Google Mozzila)

サーバーに直通だったが動的に書き換わるから…考えることが増える history.pushStateに脱線 - urlに書き戻すやつ semantic な URLをシェアするのが超大事なのがwebの世界

PWA オフライン化

オフラインキャッシュ responceをオフラインキャッシュに横流しするこれは難しい気がするな、pushで更新してそれをオフラインに横流しすれば爆速で見ることが出来たりしないかな起動自体がオフラインキャッシュでおこなわれるサーバーに依存しない形態が発生する firebaseappいいかんじ

AMPもWeb Packageng対応で再構築されるかも！？

競合

Electron chromeが Add to homescreenに… REact Native Weeb技術の Mobile App 開発環境という点で競合

インターネットがおそすぎる、一日一回だけつなぐっていいな 60fpsでうごいてほしいものだとくっそおそい先読みとかしたい、光を超えろ

初回リクエストをCDNでキャッシュオンマウスで遷移先を事前にfetch & cache レスポンスはSWのCacheから返却 dev.to 速さを最初から設計する - 更新時のcacheの履き戦略を詰めてる速さが最高のUX

IEを殺すぞ

いままではゆめ、げんじつはここから

Mobile vs Webの代理戦争じゃないの Appleはストアが良い、Googleはクロールしたいからweb, facebookは… MFI モバイルターゲットにする気持ち

PWA service workerはあってもなくても動くはずの技術 safariの 11にonfetchがあるけどonpushがない。やばい

ぱふぉちゅー

支配的なブロッキング要素を探す潰す繰り返す推測すんな計測しろ

Devtools ライトハウス preact ぴーりあくと超速webページ速度改善ガイド、買うぞ

虚無は早い重さは機能の重さ、否定するのはどうだろう

重いSQL 解像度広告

必要な速度は何でしょう。表示のスピードだけではない

k8s オラクルミッションクリティカルシステム司会はくーべるねーてるこのひとはくーばねーてす hhiroshell

本気で使うとどういうことを考えなくてはいけない？？？ ErgodoxのファームのビルドにDocker アーキテクチャー、経営プロセス

k8s を使う上で可用性の観点でやるべきこと

マイクロサービスアーキテクチャをちゃんとする - サービス境界、連携箇所に対策を施す - 疎結合にする、疎結合にするがゆえの問題があるよね - 広範囲に影響しないのでは？いやいや、する場合も多いぞ - 障害の連鎖 - Bに依存、B応答待ち、待ち側も死ぬ、Bばっか集中して死ぬ、Aも死ぬ、全部死ぬ - → サーキットブレーカーを設置 - 障害を判断して、リクエスト遮断してエラーを返すだけの子 - Istioで対処できるぞ！！ kubecon -> きゅーぶこん

Istioのおはなし

サイドカーコンテナでEnvoy アプリケーションの変更無しで入れられる、簡単便利！これいれよ IstioとCI/CDツールに依るかなりーデプロイメント - Istioでリクエストの配分率を設定可能、 1%とだけカナリーデプロイメント - istioctlでやる - CI/CDはどうなる？ spinnakerかな？ちょっとこれ後で調べる

両隣がふぁっきんかめらまんでまじでクソ

ちゃんと考慮しろ

バージョン選択

コンフィグレーション

Istioの管理・監視設定 <- これがつらそう

k8sと組み合わせる時に制約がある

あるフラグオンにするとうごかないよ… 環境作るたびにやんないといけないから大変ではある

単体の可用性を確保

従来型の障害対策を - SPOD -> 冗長化 - 障害耐性と回復性 -> 障害想定設計

ここで言うサービスとは->AP,Web,DB どこまでマイクロなんだろうかクラスタ内にMySQL　Master????, Read Replica, でデータはストレージサービスに MySQLの冗長構成 Service(ClusterIP) - read replicaにアクセス分散、スケールアウトしてもルーティングできる Service(Headless) サービスオブジェクトの使い分けで書き込み、読み込みを適切に

StatefulSet でPod配備, 落ちたら落ちた情報まま立ち上げられるマウントするストレージとか FQDNとか 1.9からGA つまりは自動再起動できるDB構成つくれんぞこれつよい read replicaのmaster昇格ができる？できなそう

%% 死なないkafka 分散メッセージ・キュー　->　これはCloud Pub/Subでいいかな透過d的な自律回復死んでる間の復旧とかリバランスとかって誰の機能でやってんの？？？？？？ Kafkaのチャットアプリ

podの名前がきれいなのはdeploymentの使い方が違うのかな… chaoskubeというツールが有る、調べる helm install labels=app=kafkaをinterval=1mごとにランダムで落とすお仕事をしてくれる kubectl logs で標準出力ログ見れるからこれでsakuraみればいいのか

リバランスの負荷高い、Zoneまたぐとき通信速度遅いので結構辛い NodeやDC自体が死んだらどうしよう

サービスメッシュ導入に必要なスキルと工数の低減

障害復旧時の負荷への対応

ノードやデータセンター障害の考慮

Oracleで実現するミッションクリティカルk8s

CNP Container Native Application Development Platform k8s周辺ツール/フレームワークを提供するやつ

CI/CD wercker(おらくるがばいしゅうしてたんだ) APIレジストリ Apiary(swaggerみたいなやつ) IaaS OKE マイクロサービスフレームワーク Istio/Envoy, Kafka, Fn Projct(OSSでつくったやつ) 管理・監視 Prometheus, Zipkin/OpenTracing, Vizceral ServiceBroker Open Service, Broker

IaaS強い Availability Domains 3リージョンの1Tb/s ホスト間低レイテンシー

性能に関するSLAをOlacleが発表ダウンタイムはほかもあるけどパフォーマンス出したの偉い

oracleにteraformのインストーラーがある

serviceでやるとどうなる？

以下をまるっと考える

Istioのおはなし

k8s を用いた最強のマイクロサービス環境をGKEで実現しよう司会はくーべねてぃす福田潔さんはくーばねーてぃす

てんえっくす 10x 1.4とか2.9倍とかじゃなくてイノベーションで10倍20倍にしようぜみたいな

GKE使ってる人ほとんど居ない問題

他のクラウドと比べて勝っている点(きゃくのやつ) - BigDataの領域強い BigQuery, Dataflow - Cloud ML (machine learning, AI) - Container (K8s)

kubectl is the new ssh kelseyhightower, kubecon 2017 keynote

かっこいいエンジニアが対象とするレイヤーがOSとか��ったけど変わった低レイヤーは気にしない、kubectlでいける kubectl は全てのエンジニアが覚えろ、デファクトになんぞ

マイクロサービスアーキテクチャ, 12-factor App Zero Opsプラットフォーム

モダンな要件ユーザビリティ 24/7 アジリティ性能マルチデバイス

それを支える基盤の要素自己修復能力モジュール化スケールすることリリースパイプライン Blue/Gree, かなりあデプロイロールバックモニタリング

NOdeの自動アップグレードを設定しておこう

メンテナンスウィンドウ, beta アップグレードが行われるタイミングを決められる素敵

workerノードがVMなのでやばいヘルスチェックしたら再起動してくれる？ノードの自動修復 - Container-Optimized OSなら --enable-autorepair な感じ

マルチゾーンクラスタデフォルトでクラスタ作るとzoneはされてしまう additional zoneデマルゾーンしたい --zone asia-x-a --node-locations asia-x-b, asia-x-cみたいのできる。これやろう既存クラスタにできるし

リージョナルクラスタ(beta) masterも複数ゾーンにできるこれわからない課金されないしやるしかないっしょ

効率性 - COS(Container-Optimized OS) コス ubuntuだとジッ道アップグレードしない - スケールアウト - HPA, pod数を制御 - クラスタオートスケーラーノード数を制御 resize --sizeでおーけー、 --min-nodes 3 --max-nodes 10 --enable-autoscalingとかできる - スケールアップ - VPA Podに対するリソース割当を制御 - VMインスタンスタイプの変更 cordonする drainする既存のnodepoolを削除

プリエンプティブるVM - 中断される可能性がある - 安価 - 任意のマシンタイプいつ使うんだろう nodeSelecter　で preentible=trueみたいなのつけて運用できるランタイム-.実行基盤の意味で使ってる servie -> TCP/UDP LB, ingress -> HTTP(s) LB データストア: Spanner, Datastore, SQL DWH: BigQuery メッセージング: PubSub 運用管理: Stackdriver Logging/Monitoring CI/CD: Container Registry, Contiaer Builder GCPブログのメルカリの所あとで見る

ISP Cloiud Edge

serviceでは

ノードプールをちゃんと分けて運用する分けた先にsakuraとか配置した方がいいのでは？？？ cordon->drain->再生性、面倒だからauto-repairしようね

0 notes

miusukeeee · 9 years ago

Text

GCP Next Tokyoのログ

基調講演

4年前から登録者が50倍になってる程度の注目度インフラ設備投資は年間99億ドル投入成長度はほとんどすべての項目が150%以上の成長。2500%とかも PoPはAWSの1.5倍、さらに年内に10以上のDC作る

Lift and ShiftじゃなくてLift and Transform

これはテーマとしていろんな場所で色んな人が言っていた

エキサイティングなのはソフトウェア。でもそうじゃないことに忙殺されている。。 ex) インフラ、ネットワーク、プロビジョニング計画、予算、その他

snapchatもGCPに移行(2Mquery/sec) サービスをスケールさせるのに、エンジニアはほとんどの時間をスケールさせたりデータセンター管理に使うことになるし、成功すればするほどそれは頻繁に、また大規模に組み換えが必要

サーバレスアーキテクチャ

googleもyoutube,gmail,Apps全部自動化されてOSのパッチも当てないしインフラ何にもしないつまりはNoOps,ローコストでいけるしデータドリブンで大きくしたり小さくしたり出来る

18coreしか要らないのに16,32しかないから32…みたいなのは無い 90secでクラスタ作成できるから使ってない時だけたたんだり

VMネットワーク接続が16Gb/sec これがやばい 15sec以内に1,000,000PS

値段の話

AWSと比べて平均59%のコストダウンになる 1min単位で課金されるし、事前に大きなのを買っておけば安くなるが、なによりすごいのがこれが自動的に適用されること

なんでこんな安い？ (パーツから作ったから？)他企業と比べて200%のプロセシングパワー、電力効率くっそ高いし、再生可能電力購入量がアメリカナンバー1 これはデロリアンで2回タイム・トラベルできるぐらい

セキュリティについて

セキュリティはGoogleの事業のコア物理的なレイアウト、ネットワーク、施設、deploymentなどすべてのセキュリティをGoogleが担保する (2段階認証や楕円曲線暗号とかもそれから出てきたもの)

パフォーマンス

オリジナルのファイバー、パケットトランスミッション 1Pb/sec overの双方向トラフィックがGCP(google)内にある(インターネットの総量のx4)

可能であるを　簡単であるに

stackdriverの紹介

AWSでも使えるロギングもかなり優秀

kubernetesの紹介

containerのオーケストレーション 1.3のfederationで、複数のクラウド間で利用できるようになる！！ (補足, 1.2で複数のリージョンをまたげるようになったんじゃなかったっけ？)

(中略)

BigDataの専門技術集団(RecTech)

あんまりおもしろくない

分析系

Cloud Dataflow データをコンシュームパラレルエクスキューション

蓄積&分析、ではなく、ハイブリッド-一元管理/動的ポータビリティ

「googleが進むために行う全ての改革、それをも提供し続ける」

1.RoomB シームレスな移行のやつ

正直出るのを間違えたと思った。ネットワークのレイヤーが低すぎる話で75%ぐらいわからなかった

Cloud Networking

高スループット14Gbps 同一ゾーン内のVM間プライベートネットワーク VMライブマイグレーション

リージョン単位でサブネット作ったりサブネット単位でアクセスやオペレーターの権限管理

GCP内でのGCE,GAE,GKEとか…は一つのグローバルVIPを持つそこでGCNでサービスの仮装グループ化ローカリティや傷害分離など

完全に出るの間違えてる

各レイヤーを横ではなく縦で管理する考え方(ローカライズされたDB、レイテンシ担保するためのマッピング) ちょっとこの辺理解できてないので、メモは別途共有してほしい人だけにする。

とりあえず言えるのは、ネットワークの変更の自動検出行って高するーぷっと出してパブリックIPの水平スケーリングして…ってすごい、けど全力出させるサービスはうちにはない

2.RoomA Cloud DataflowとPub/Sub リコメンドのためのストリーム処理基盤

spotifyの事例(日本ではサービスしてない音楽配信サービス) 70万/secのイベントを処理するのにKafka0.8とか使っても無理だったからCloud Pub/Sub使った話

Cloud Pub/Sub理由

未配信データを保持できる(max 1week)

At Least Onceな配信が保証される(queueとしていける)

queueだせばグローバルで利用可能(リージョン意識せず行ける)

REST APIがシンプル(clientのSDKつくっちゃえって思ってたから)

運用の責任がない🌟

「毎秒2Mイベントの処理をする」のが目標値

ScioというsparklikeなdataflowのSDKの紹介

cloud pub/sub -> ETL using cloud dataflow すべてのデータを入れるのは困難なので、BigQueryでプロトタイピング→group by key -> Cloud Datastoreに入れてレコメンデーションこの辺はPOCっていうspotifiの発表に詳しく書いてある

** big queryからdatastoreにいれてレコメンデーションというのはおもしろい(転職サイトとか滞在時間を伸ばすタイプのサービスだとやりようがありそう)

3.RoomC GoogleAppEngineで構築するNode.jsアプリケーション

consoleからdevバージョンなどを起動するとドメイン当てられて簡単に試すことが可能また、migration trafficで試したものをポチッと本番に乗せることが出来る split trafficでN%と振り分けができる (カナリアデプロイメントとかABとか色々出来そう)

ちなみにdockerで動いているため、sshからdebugmodeに入ることでdocker psできるし、imageを外出ししてkubenetesでやることも出来る

const gcloud = require('gcloud'); const pubsub = gcloud.pubsub();

これだけでpubsubつかえる

ここから他のGCPサービスの紹介になってきてる

StorageはCloudStorage BigQueryではqueryをjsでかけるから遅いけど楽しい

nodeだとdebugはすごい楽 $node --inspect bin/wwwとかでchromeのdev consoleが使える stackdriverでbreakpointの代わりにwatchpointつけると動かしながらログ出せる

4.RoomD NoOps Stackdriver

モニタリング、Logging、診断のSaaS エンジニアが速度と可用性を維持するツール可視性に手間がかかるのは無駄というところから始まっている RDS,kinesis,BigQuery,nginx,mongo....などの監視がサイロのように閉じていると意味が無いので統合させる

洞察力 = alerting + monitoring + logtrace 抽象化して洞察して…アプリケーションに集中→NoOps

uptimeのモニタリング、ロギング、デバッグ、トレース、エラーレポーティングログの検索やフィルタリング、AWS,GCP横断などなど

ある地点のデータをドリルダウン、ログを見たりその時点での他のデータを横断できる

alertを作る。項目ごとに閾値を設けて…

Stackfriverのデータを分析するなら BigQuery, Datalab統合 stackdriver -> loggin -> exoprt ができる

Datalab jupiterベース python BQはログデータ、datalabはmetadataをつかう

iPythonのnotebookになってるからpythonでゴリゴリ出来る

他のクラウドやオンプレミス対応するかもしれない！！！！！

いまbetaなので無料！！！

5.GKE

kubenetes 操舵手という意味。統治者と人工頭脳の語源。かっこいいかっこいい

複数クラウド&ベアメタル環境サポート

コンセプト

ポッド密結合したコンテナの小さい集合静的サイトジェネレータ& webサーバーバイナリとか

デプロイメント望ましい状態にするループ ex webアプリケーション

サービスロード・バランシングされたバックエンド

ラベルメタデータ

1回かけばどこでも稼��する →ネットワークモデルサービスのロードバランサ�� ingress PersistentVolums

microkubeみたいなやつでローカル環境に作る

CA abemaTV

API層で利用ちなみに動画キャッシュはAkamai使ってる(理由は聞けず)

カナリアデプロイメントをしてる。kubenetesでどうやって…？？1アプリケーションにnode二つ以上持ってるのかな

ServiceはVirtualIPとDNSを持つ kube-proxyで管理するべき

Auto Scalingも実装されたが、kubenetesのスケーリングとGCEのスケーリングをうまいことカスタマイズしないとつらいカスタムメトリクスはまだα

google persistent storage使える！！！！

まとめ

最後のセッションでの電池切れがつらかった。新しいマシンが欲しい…

イベントタイトル通り全体的に「次」を押している Googleを支えるインフラを実現するためのアプリケーションをオープンに使用させるクラウドサービスなので、細かいところはAWSのほうが便利だが圧倒的なパフォーマンスが出せることには変えられないと思う

特に分析周りは推しているだけあって力を入れているのを感じる。インフラの面からもスケールの速度と柔軟性が必要なのでGCPで打つべきだと感じた

また、rktには当然触れないがContainerEngineは注目度も高く、面白い存在なのでGCPではなくkubenetesUGの方を追うべき

0 notes