gcp ja night 31 参加メモ¶

K8s の RC と Service は独立した構成要素。 RC は Pod の死活監視、 Service は L4 LB 的な動きをする。

GKE は 5 node まで無料で使える ので、安く動かせることが多い。

BigQuery の操作には Cloud Datalab (Jupytter Notebook 派生) が便利。 python で BigQuery を動かしたり pandas などを動かすことができる。

今日の話は 2015 Borg -> GoogleがBorgの詳細を公開 - InfoQ

コンテナー は chroot ulimit とかで実現されている

コンテナ 軽量ポータブル 効率性

Borg は Google社内で利用しているコンテナエンジン

Borg は DCaaS (Datacenter as a Service)

• Borg は DC の OS

Borg の設定ファイル は DSL だな 「some = { some = { some = some } }」 みたいな

• (感想) Borg で Kubernetes (K8s) を管理するんだなこれは

scheduler から BorgMaster に設定が渡され、コンテナにいろいろ展開される

コンテナ管理の課題 とは 複数サーバーのデプロイ、ノード障害時のリカバリー、コンテナ障害時のリカバリー、コンテナのアップグレード

K8s は Borg の対外的な実装、K8s の実装者は Borg の実装者と同じ

CNCF (Cloud Native Compiuting Foundatoin) で K8s の開発を支援

Container Engine は K8s のhosted版

(疑問) 実際 Docker を直接動かしてるの？ Docker 互換の何か？

ポッド とは 複数のコンテナを同じホストで動かしたもの

多数のポッドを識別する には 各々のポッドに種別のラベルを設定して識別

• (感想) ラベルはタグ的な

レプリケーションコントローラー は ポッドの実行状態を管理

• 管理対象はポッド

サービス とは エンドポイントを抽象化したもの

• 仮想IPが割り振られる

• ポッド間 は ラウンドロビン的に Load Balancing する

yaml ファイルに type: LoadBalancer とかかくと LoadBalancing してくれて便利

(感想) K8s は GUI でコンテナーの状態を表示する機能がありそうで、便利そう

Google Cloud Platform を使ってみよう ってイベントある

GCP NEXT 2016 (参加費 499ドル) ってイベントある

takusuta では AWS/GKE 利用している

takusuta

• Web版は GKE で作成

• モバイルは AWS Web は GKE

• GA 前だけど GKE 利用したかったため、利用した

GKE ざっくり説明

• K8s のフルマネージドサービス

• すごい安い

• 5Node まで無料なので、安い

• Pod と RC (Replication Controller) をしっていれば何とか使える

• Service は Pod に対する L4 の LB な見たいな奴

• kube-proxy が動いていて便利

GKE 構成した場合

• Service に SSL 証明書置けない

• GCE の LB をおいて, GKE を NodePort として起動して使った

• Cross Region LB 構成ができて、 CPU/リクエストの閾値を指定して、変更できる

• ただ、 Zone によって性能に差があるので、気をつける

GKE の構成

• Google Cloud SDK を利用すればワンストップで利用できる

• gcloud コマンドで動かせる

• コンテナ作成時しか指定できない設定もあるので、注意。作り直しになる

• gci.io ってコンテナのアップロード先が地域毎に存在する、日本は asia.gcr.io を利用すると早い

• kubectl でコンテナにアタッチできる

GKE 活用例

• 5 ノード以下は無料なので、大きなクラスターは作らない

• ennis-asia-app-001 がポッドの命名規則

  • ennis はプロジェクト名、 asia はリージョン、app コンテナの種別、001 はユニークキー

• インスタンステンプレートを更新する API がないので、不便

• gcr へのアップロードは、遅い

• アップロードは Jenkins でビルド後にアップロード、 hubot でリリース指示

• 今のところ gcr は落ちたことなさそう

• gcr のイメージの名前は、ハッシュなので、消し辛い。そのうち改善するでしょう

• kubectl rolling-update ってコマンドがあって、一台ずつ inc/dec してくれる

• multi-container-pod の場合は同じ名前ではアップデート失敗するので、駄目

• クラスタの方は gcloud コマンドで制御

• RC の数は kubectl で replica を制御

• Cloud Logging によるログ管理もでき、 Pod ごとにクラスタごとに検索できる

  • 標準の状態では標準出力もみるので、ノイズが多い。ログ名とかレベル名とかでフィルターできるようにしよう

• Monitoring は StackDricer ベータなので、 Monitoring できる

• Kubernetes dashboard は表示が不正確で、使い辛い

• Kubedash 結構使えるので、便利

まとめ

• 簡単、安い、将来へ期待

• 本番でとりあえず使えるのでは

内容が被った

• 構成や使う動機が同じ

どんなプロジェクトだったか

• 現実世界の混雑度合を IoT を利用して検知を行う系

• 必要な物

  • センサデバイス

  • 20億レコード/月 を保存する DB

  • デバイスの管理、解析をするバックエンド

  • 画面を実際に提供するフロントエンド

• 1.5ヶ月で作成する

• 3人で作った

  • フロントエンドの人がいて、すごいできた人だった

• プロトタイプ的なものなので、人が少なかった

• 下の二つ話す

  • デバイスの管理、解析をするバックエンド

  • 画面を実際に提供するフロントエンド

• 設計

  • マイクロサービスアーキテクチャー

何が問題だったか

• 資源の無駄遣い

• 人が少なく、Ansible を利用していたが、無理がでた

• リリースなどの Ops の作業が難しかった

どう解決したか

• フロントエンド/バックエンド

  • GKE は GCP の他のサービスと連携できる点が良かった

  • GKE は CI が行いやすい

    • GHE -(CI)-> circleci -(upload)-> gcr -(ローリングアップデート)-> GKE

  • デプロイとロールバックが容易だった

  • Dockerfile/Docker Image ですべてコンテナ管理できて便利

  • モジュールなどを細かく記述できるので、マイクロサービスと親和性があった

  • GKE L7LB (Load Balancer) を使った

    • 100万リクエスト/s をウォームアップなしでさばける

    • SSL

    • http2

    • url-map

  • HTTP LB はまだ Beta

  • セットアップの記載は複雑

  • Google Cloud Monitoring を利用

• 20億レコード/月 を保存する DB

  • Streaming Insert でほぼリアルタイプでセンサデータをインサートできる

  • BQ はリアルタイム性が必要ない分析には速度十分、ちょっとまっても良い処理

  • 保存、分析料金が安い

  • GCE で静的なIP取得してほっておくとお金かかる、、、

• BigQuery へは fluentd でデータを入れている

GCPを使ってみてどうだったか

• k8s はマイクロサービスアーキテクチャに最適

• k8s + GKE は時短になる

• BQ ででかいデータの分析ができる

• -> IoT サービスと GCP は親和性が高いのでは

GCE の Autoscaler と CloudLogging

• 配信の一部で HTTP(S) LB と GCE を利用

• fluct に所属、純国産 SSP(SuplySidePlatform)

• 広告素材の CDN

• インプレッション計測サーバー、計画値ゅ

• 利用したもの

  • GCE

  • HTTP(SP) LB

  • Autoscaler

  • Cloud Monitoring

  • Cloud Logging

  • BigQuery

• official に発表されたものが中心

• ハマったところや、利用したものを書いた

• LB は組み合わせて利用するもの、 AWS とは異なる感じ

GCE の Autoscaler

• CPU utilization

• Cloud Monitoring Metrics

• HTTP LB serving cap

  • インスタンスごとの RPS(RequestPerSec) を見る

管理方法

• gcloud をラップしたコマンドを利用

• さらに Makefile 書いて、 make コマンドで動くようにしている

Cloud Monitoring

• Agent方式

• Disk Usage, Memory Usage が見られる

• Network, Load Average

Cloud Logging

• 広告といえばログ、ログといえば解析、解析といえば BigQuery

• Cloud Logging は google 提供の td-agent

  • 入れると設定サンプルとかごっそり入れる

• tag 単位で export できる

• BigQuery, Google Cloud Storage に export できる