オーストラリアで勉強してきたMLデザイナーの口語自由詩

主に、データ分析・機械学習・ベイズ・統計について自由に書く。

Kubernetes Meetup Tokyo #22 レポート

kubernetes k8s EKS ECS AWS kubectl

以下のイベントに行ってきたので簡単にレポート書きます。

k8sjp.connpass.com

twitterでみんないろいろつぶやいているので、k8sjpのハッシュタグを見るのもいいかも(｀・ω・´)

twitter.com

内容

LT前の懇親会でのご飯(｀・ω・´)

f:id:yukinagae:20190828233424j:plain
ご飯

LTではなぜか分割キーボードと遊舎工房の宣伝が(´∀｀*)

f:id:yukinagae:20190828233427j:plain
分割キーボード

ここから本題。

AWS EKSを用いた開発環境の構築 by SmartNews

TODO: スライド資料へのリンクを後ではります。

  • SmartNewsってUSにもあるらしい(｀・ω・´)

サービス概要

  • ニュース配信
  • 広告配信

どちらも

システム概要

  • モノリスからマイクロサービス化
    • もちろん完璧ではない
    • 古い業務システム部分が残ってたりする

組織体制

k8sでやりたかったこと

  • 開発者が環境を簡単につくれる
    • GitHubにブランチをPushするだけ
  • その環境にユニークなURLでアクセスできる
    • それぞれendpointが用意される

k8sでやっていること

  • featureブランチ毎にLBで振り分ける
    • feature-a.smartnews.xxx -> feature-aのSVC + Deployment
    • feature-b.smartnews.xxx -> feature-bのSVC + Deployment
    • feature-b.smartnews.xxx -> feature-cのSVC + Deployment

インフラ部分の構成

  • Terraform
  • k8s
    • ALB Ingress Controller
    • Nginx
    • Monitoring: Datadog

アプリケーション部分の構成

  • k8s
    • Service
    • Deployment
    • ConfigMap

tips

  • annotationでdeploy-timestampをつけることで、必ずapplyされるようにしてる。これ必要なんかな(´∀｀*)
  • EKS環境はbranchが削除されるとともに削除されるように1日1回ジョブを走らせている
    • branchを消し忘れると消えない（※mergeした時に消したほうがいいよね、とか）

これから

  • Staging/Production環境へのk8s導入
    • スケールアウトの速度を改善したい: 例）号外をうつときはスピード重視
    • サービスメッシュの導入: 検討するらしい。サービス間連携とか楽になるのでは？

Q&A

  • 質問: 「ECSを使わずにEKSを使わなかった理由は？」
    • 回答: 「本番環境でECS使ったりもしてるが、色々な背景で今回はEKSを使っている」
    • 感想: なんとなく既存のECSがいろいろな事情（技術的・政治的？）で使いづらかったので、（技術検証も含めて）今回はEKSを採用した、ということかな(｀・ω・´)

はてなでのKubernetes利用の取組みとこれから by はてな

speakerdeck.com

  • Mackerel / SRE

  • ドッグフーディング

    • コンテナ運用してみる
    • Mackerelのエージェントの動作確認
  • インフラ管理コストの削減 <- わかる
    • 複雑なサーバプロビジョニングの管理からの脱却

なぜk8s？

選択肢

  • 自前？
  • マネージド？

自前にした

  • EKSにJapanリージョンがなかった
  • AWS以外ではネットワークのオーバーヘッドが大きく運用が難しい

技術的な話

課題

  • 高い学習コスト
    • そもそもk8sは複雑
    • 運用が属人化してしまう
  • 膨大なエコシステム
    • 運用にあったサービスやツールを選ぶのは大変
  • クラスタのアップデートへの対応
    • マイナーリリースは3ヶ月毎に実施され、3リリースブランチがサポートされる
    • リリースに追従する必要がある
    • アップデートに失敗すると困る。クラスタのBlue/Greenしたいよね
  • 運用リリース不足
    • メンバーの退職・異動
    • クラスタが放置気味に。。。汗
  • クラスタアップデートに失敗
    • 脆弱性への対応の遅れ
    • 運用リソース不足
    • etc

撤退

撤退の話できるの本当にすごいしありがたい。 こういうしくじり話を自分もしていきたい気持ち(´∀｀*)

  • 本番環境
    • 並行稼動していたので切り替えるだけでOKだった
  • ステージング環境
    • VMで全て再構成

経験やノウハウはたまった

これからの取組み

  • k8s != コンテナによるシステム運用の実現を優先させる
  • 社内で運用ノウハウのあるECSへ移行する
  • 最終的にEKSへ移行
    • マネージドで運用負荷の削減
    • 最悪EKSで失敗してもECS（コンテナ）によるシステム運用は担保

まとめ

  • 構築 != 運用
  • クラスタ運用を見据えた体制を整えることが大事
  • スモールスタート・並行運用・撤退可能な設計を心がける

紹介スライド・記事

PayPay での Kubernetes 活用事例 by PayPay

TODO: スライド資料へのリンクを後ではります。

技術スタック

  • kafka
  • Aurora
  • datadog
  • new relic

k8s事例

  • 2018/12/04: 100億円あげちゃうキャンペーン
  • 2019/02/12: 第二弾100億円キャンペーン

問題

  • アクセスの急増！
  • Core機能のAPIに予想以上のアクセス集中が。。。汗
    • Service/Deploymentのmanifestを複製してしのぐ
  • パフォーマンス・チューニングの前にボトルネックの調査
    • Docker imageにNewRelicを入れる？
  • アプリケーション間の認証のサービスに負荷が集中
    • Service/Deploymentのmanifestを複製してしのぐ（2回目！）

今後やりたいこと

Kafka on Kubernetes

  • アプリケーション用途
  • ログ収集用途: ログをロストしないために間にkafkaをかませている
    • [各アプリケーション] -> [kafka] -> [Logstash] -> [Elasticsearch]

Canary Release

  • 少しづつリリースしたいよね
  • 既存のデプロイフローも改善したいよね

既存のデプロイフロー

  1. アプリ修正
  2. Jenkinsでbuild & publish
  3. k8sのmanifestを修正
  4. devへのdeploy

新しいデプロイフロー

  • githubを見れば環境の状態がわかるようにしたい
    • secretは除く
  • 本番リリースは一部の権限を持つ人に限定したい

2ブランチ

  • master: 開発・ステージング環境用
  • production: 本番環境用

検証は終わったので、これからサービス展開準備中らしい(｀・ω・´)

技術スタック

メトリックスみたいよね

  • datadogに rollout-pod-template-hash ラベルの値を送信する（※環境変数として埋め込む）
    • この値でフィルターしてメトリックスを見る
    • 本当はdocker imageのtagが取得できればよかった

LT x 5

順不同

speakerdeck.com

speakerdeck.com

speakerdeck.com

speakerdeck.com

おまけ

  • 会社の同僚がKuberentes実践ガイド（サイン本）当たってました。うらやま(´∀｀*)

Kubernetes実践ガイド クラウドネイティブアプリケーションを支える技術 (impress top gear)

Kubernetes実践ガイド クラウドネイティブアプリケーションを支える技術 (impress top gear)