CTO Meetup Kubernetes導入とその後のレポート

最初に

https://flexy.connpass.com/event/124655/

唐突にみて面白そうだと思って行ったのでそのレポート

目次

セッション

急成長中スタートアップでのKubernetes導入事例

トーカー：横山哲郎さん

資料：そのうち公開されることを祈る

• スタートアップキメラプロダクト：技術負債的な
• なぜ生まれるか
  • 勢いファースト＋
  • 若くてナイーブなエンジニア
  • 多数の副業エンジニア
• そこにKubernetesをいれた話
• Kubernetes をいれるとどうなるか
  • 規律化(コンテナ運用を行う上でコンテナを疎にする必要がある)
  • デプロイフローが大変になる。
• ZEALS社の事例
  • 国内初Chat内決済にも対応、これまでのフィード広告の代替としてMessangerやLineのChatBotを使うサービス
  • 五ヶ月くらいの規模をかけてKuberntes(Azure -> GCP)を導入
• 構成
  • ChatBotらしくPub/Subを使ってるメッセージングをしている。
  • 4つのMicroservices：管理プラットフォーム, Subscription, Pub, Browser manipulator(トークンから得た情報をもとに決済する)
  • マイクロサービスとKubernetesは相性がいい
• 導入理由
  • ディストリビューテッドで信頼性を確保するのにコンテナオーケストレーションは相性がいい。
  • インフラ、サーバーなど横じゃなくて垂直でやるほうがオーナーシップ的によく、エンジニア面の成長性を感じた。
• いれてみてよかったところ
  • 自立化、オートヒーリング、なめらかなデプロイ
  • コンテナを動かすと、疎を矯正される(規律化)→運用しやすくなった
  • エンジニアの流動性がすごいので、宣言的アーキテクチャでないとこの先やっていけないので、宣言的アーキテクチャのkubeはよかった
  • UNIX哲学：一つの目的を確実にこなす
• つらかったろこと
  • キメラの解体をしないといけない
  • フルスタックなフレームワークを切り刻んでビルドパイプラインをつくる
  • 4つのマイクロサービスは中途半端にマイクロサービスだったので(どっかしら依存してたところとか) 逆に大変な場面もあった
  • Continuous Deliveryが決定版がない→結局GCPのCloudBuildをカスタマイズしてつかった
• まとめとしては、「政治力」、「腕力」、「オミット力(これ以上はやりすぎると)」が大事かと

ChatworkにおけるKubernetesの活用

トーカー：坂本諒さん

発表資料：後日あげられることを祈るしかない

• ”どう導入したか”、より運用メインの話
• Chatwork : 日本初のビジネスチャット
  • Kubernetes, Kafkam HBaseなどEC2でホスティングしているもの見ることが多い
  • 入社したらKuberntesが導入された状態だった
• 導入タイミング
  • 2016年末、Scalaを使うということでメッセージング部分のリプレイスするときにKuberntesを採用した。
  • ECSでもよかったが、拡張性の高さ(エコシステム等)などで観点からKubernetsを導入した
• 導入箇所
  • リプレイス部分
  • Webhook
  • Oauth
• 運用であったトラブル:意外となかったが、強いて上げる
  • workerのディスク溢れ：コンテナのログのローテーションができてなかった。→本番稼働二週間後ぐらい
  • ステートレスなアプリかと思ってたらステートを持ってた→クラスタ内部に依存部分があり、クラスタのバージョンアップ時に発覚した
• AWSでうごかしていて、EKSもない時代で、CloudFormationでKubernetes on AWSを実現した
• 運用を楽にするツール
  • datadog：ライブコンテナモニタリング機能がええ。
  • ログはfluentd：kube-fluentd-operator(vmware)というのを利用
  • cluster-autoscaler: podのリソースに基づいてノード自体をスケールしてくれるツール
  • kiam : podにiam roleをつけてくれる
  • falco: コンテナ内のプロセス監視
  • Guard : Kubernetesユーザのgithub認証を簡単にするツール
• しんどいこと
  • 間違いなくバージョンアップ
  • Kubernetesは三ヶ月に一回更新される
  • EKSローリングアップデートはあるが、できればやめてほしいみたいな書き方をしている
• 良かったこと
  • operatorをつかうことで、そもそもの運用の自動化することも可能
• 難しいこと
  • dev側の学習コスト：分かる人がメインで対応しちゃうし、属人化しちゃう
  • SREとしても布教ドキュメントの対応はしている
  • CI/CD　
    • まだいろんなツールが群雄割拠している感じ
    • Concourse(CIOps)を利用しているが、yamlで全部書くので、2000行とかになってしまうし、なかなかしっくりキていない。
  • version upへの追従：三ヶ月に一回は確実に守ってくるし、前3バージョンしか保証してくれない
• 今後の展望
  • 全アプリケーションのKubernetes化：phpアプリも絶賛対応中
  • EC2に特化しすぎていたところを解体中で特にnginxまわりが魔改造になってるのでなんとかする
  • ELSへの以降予定

    

    良かった点

Do you like Kubernetes?

トーカー：寺田佳央様さん

発表資料：slideshareは特定できたので後日あげられることを祈りつづけましょう。

• なんのためにKubernetes？？ちゃんと考えてる？
• ほんとにKubernetes好きですか？→好きなところもあるが、嫌なところもある
• Kubernetesをやる前に、「マイクロサービス」、「モノリシック」とか、まずそれらが抑えられていますか？？
• 両方dev, opsが両方共やってる人が重要。
  • Kubernetesはdev, opsどちらの知識もないと全然効果を出さない
• どんなものがKubernetesに向かない？
  • スケールアップが必要なアプリケーション：むかない
  • スケールアウトができるものは向いてる
  • 変更に強いシステムを作る：すごい向いている
  • 一回作ったら昔の基幹系みたいにバグ修正とかちょこっと追加機能とかであれば、圧倒的に教育コストがかかるのでやめたほうがいい
• 他社の栄光事例を真似ても意味はない。自社にとって最適な構成を一生懸命考えるだけ
• Kubernetes以外の選択肢も考える。盲目にならないでほしい
  • Web App for Containers：圧倒的にAKSより教育コストがない
  • サーバーレスが向くのであればそうするべき
  • 全機能は使わなくてもいいし、便利なところを便利な機能を作ろう
• 12Factor App やTDDやagileやバリューソリューマッピングなどを洗い出してその際にKubernetesを使うべきだと思う。
  • いきなりKubeではなく積み重ねでしかない
• 様々なトラブルあいますが、それを乗り越えてより良い製品・サービスを作りましょう
• Kubernetesは自分で育てていくものです。さらに、英語力の差が技術力の力の差になる。

  

  Kubernetesは技術の積み重ね

パネルディスカッション

ローリングアップデートについて

• 絶対にやめたほうがいい、壊れる可能性がある. やる場合は、Clusterをのこして、Cloneして、Updateして、大丈夫そうなら、向き先をきりかえるようにしましょう
• ローリングアップデートすると、元にもどせない。
• 更にクラスタ数は小さく抑えるべき。

ローリングアップデートしたときに壊れたらどうなるの？

• vmレベルのupgrade
• kubectl noでみると何もみれなくなった

CDが大変な件について

• gitopsがいいかも？
• Concourseを使ってるけど、credential(認証系)をどうKubernetesに持たせるか。
• algoCDは絶賛開発中らしい。
• リポジトリとかちゃんとやらないと、ステージングで全部切る等やらないと大変になっちゃう。
• chatworkはDockerで切って、アプリで切って、ヘルムで切るらしい
• azure devopsをつかうという選択肢もありかも。 SaaSのサービスでチームサービスファンデーションサービス。
  • sampleが簡単に作れて、ウィザード形式でdeplpoy先がKubernetesとかできる。
• CloudBuildは、コンテナネイティブで癖はつよいがおもしろい。
• (他の会社さん)CircleCIとかでやってる
• KRUDビルド経由
• spinnaker(メルカリとかにつかってる)とかjenkinsとか
• 機能が豊富なもの向けでとにかく重いイメージ。なかなか小さいチームで見るのは難しい

どのフェーズのシステム / チームからKubernetesを導入するべき？

• 短期的に見たらペイしないが提供するサービスがどんどんのびる時、がつんとにきりかえると痛みが緩和するために導入を考えたりする。なにかしらのきっかけがないと。
• フェーズというとむずかしい。そのサービスがどういう風に成長しますかってなったときに。サービスが追加されていく可能性があれば検討するべき。変更が加わらないなら別に。って感じ。マイクロサービスをスケールアウト、インするのにKubernetesがむいてるので

Kubernetesのマニフェスト管理はどうしてる？

• 基本はインフラもち。エントリーポイントをデベロッパーようにおいてる
• Clusterの管理はSRE, アプリ, helmはdevに持たせている
• ソースコードとDocker、yaml関連をサービスごとにおいてる

エンタープライズjavaとそっくり

IstioとかはDIとそっくり。

コンテナ監視について

• autodiscoveryがないとはなしにならない。
• プロメテウスのほうが拡張性があるが自分でチューニングしないといけない。
• azureの場合だとインストール時に監視用のエージェントをいれてくれる。AKSのうりのひとつ。ログの管理ツールとな面倒見ないといけないのがつらいので

Kubernetesにしたことでの後悔

• Kubernetesにして後悔したことはない！ オートスケールしてくれる面

どういう人がKubernetesを触るとやばい？

• コンテナやりたい、マイクロサービスやりたい！！！って手段が目的化する人がやばい。

感想

非常にメッセージ性の強い内容でしたが、僕は寺田さんの発表が1番面白かったです。 スタートアップ、中小、ベンダーという三視点から話が聞けてとてもよい勉強会でした