Kubernetes(k8s)導入とその後【前編】3社の事例に見るKubernetes導入経緯と構成、向き不向きの現実

2019年4月2日に開催されたCTO meetup。今回は、マイクロサービスやDockerの台頭とともに注目度が高まっているKubernetes(k8s)をテーマとして、3名のエンジニアにたっぷりと語っていただきました。LTで三者三様の導入事例をご紹介いただき、その後はパネルディスカッション形式でトーク。Kubernetes導入と運用においてポイントとなる部分が議論されました。Kubernetes導入を考えているエンジニアや企業様必見のレポートです。

●横山 哲郎 氏 <モデレータ>
“金融SIerにおいて業務管理システムの開発・運用に携わったのち、2012年よりドリコムに参画し、海外向けブラウザゲーム、ネイティブゲームをテックリードとして担当。 2014年から株式会社MUGENUPに参画し、サービスの企画からインフラ構築、アプリ開発全般に従事する。 2015年より同社CTOに就任し、技術戦略の策定、情報セキュリティ管理支援基盤の構築、新規事業開発に取り組む。 これまでのエンジニアリング経験を社会に活かしたいという思いから、ITサービス企業数社の技術アドバイザーおよびプロダクト開発を行っている。”

●Chatwork株式会社 坂本 諒 氏
“2017年7月からChatworkで働き始める。入社直後から、Falcon projectで導入されたKubernetesに関わる。 Kubernetesのほか、HBaseやKafkaなど、ec2でホスティングしているミドルウェアが主な担当。 ”

●日本Microsoft株式会社 シニアクラウドデベロッパーアドボケイト 寺田 佳央 氏
“2001年 サン・マイクロシステムズ株式会社に入社し GlassFish エバンジェリストとして活動。 2010年 オラクルのサン買収後、日本オラクル株式会社で Java エバンジェリストとして活動。Java の最新技術情報の提供や、Java コミュニティ活動の活性化を、日本 Java ユーザ・グループ(JJUG)と共に行ってきた。 2015年7月、日本マイクロソフト株式会社に移籍し、移籍後もなお Java エバンジェリストとして、マイクロソフト・プラットフォームにおける Java の利用促進・啓蒙活動を実施中。 2018年7月より、マイクロソフト・コーポレーションで日本人初のクラウド・デベロッパーアドボケイトとして活動を開始。 2016年7月、日本人で 2 人目となる Java Champion に就任。JJUG 幹事の一員でもある。
Blog: https://yoshio3.com GitHub: yoshioterada Facebook: yoshio.terada Twitter: @yoshioterada”

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

スタートアップが抱え込む技術的負債や修正困難な問題の要因とは?

横山:横山哲郎と申します。現在技術顧問として活動しており、金融エンプラSIやソーシャルゲームのテックリード、また、立ち上げを目的とした速度重視の新規プロダクトなど幅広く経験を積んでいます。
個人的にソフト開発を成功させるために大切にしているのが「禁欲」です。これは、欲を出すと損をするということです。新技術を無闇に取り入れるのではなく、その技術が得意としているところは枯れた技術でも使いまわすことも重要だと考えています。KubernetesやGo言語なども該当しますが、新しい技術を導入する際は禁欲というキーワードが重要になることを前提に聞いていただければと思います。

さて、今回は急成長中スタートアップにおけるKubernetes導入事例をシェアしたいと思いますが、概念として先にお伝えしておきたいのが、「スタートアップキメラプロダクト」という私の造語です。

・勢いファースト
・若くてナイーブなエンジニア
・多数の副業エンジニア

スタートアップキメラプロダクトは、これらの要素が組み合わさってできあがります。スタートアップが成長した後に生じる技術的負債や修正困難な問題は、主にこれらを要因となって引き起こされると考えられるでしょう。今日お話するのは、こういったプロダクトを抱えた企業でKubernetesを導入した事例です。

4つのマイクロサービスがコンテナオーケストレーション環境にフィット

横山:あわせて、Kubernetesがもたらすものを要点として2つお伝えしたいと思います。

・現代のトータルエンジニアリングカオスの規律化
・リポジトリ構成、デプロイフローが複雑化

特に、リポジトリ構成、デプロイフローの複雑化という面で、株式会社ZEALSの「会話広告fanp」というChatBotサービスを事例としてご紹介します。LINEやFacebook広告のリンク先をボットに設定し、ユーザーとの会話を通して商品・サービスを提案、コンバージョンを獲得することが可能なものです。先日藤田ファンドらから3.5億円の資金調達も実施して急成長しています。
Kubernetesの導入理由は具体的に2つ。まず、サービスが複数のマイクロサービスによって構成されていて、お互いの信頼性を確保しようとしたときに、コンテナオーケストレーション環境は非常に相性が良かったというのが一つ。二つ目は組織的、人的な要因です。インフラやサーバー、フロントといった横軸でエンジニアを分けるよりも、垂直にオーナーシップを持つ方がエンジニアは成長しやすく、長期的にもいいだろうと考えました。
Kubernetesを導入してからはAzureをGCPに入れるクラウド移行も含めて5ヶ月ほど経過しています。パート職員も含めて2~3名のメンバーで移行作業中です。

簡単に構成をご紹介すると、すべてをKubernetesにするのではなく、GCPのマネージドサービスを積極的に使っている形です。

kubernetes

kubernetes

横山:ChatBotらしくPub/Subメッセージングが主流になるサービスのため、マイクロサービスと非常に相性がいいのです。マイクロサービスは管理PF、Sub、Pub、Browser manipulatorの4つです。Kubernetes自体はさほど難しいことはしていません。
細かな利用技術について、オーケストレーションはもちろんKubernetes。コンテナはDocker、マニフェストはKustomizeで生成しています。暗号はkubesec+Cloud KMS。CDに関してはCloudBuildで、監視ツールはDatadogです。

Kubernetesは現在の高コストで流動性が高いエンジニア組織の性質にもマッチする

横山:導入して良かった点は自律化です。オートヒーリングですね。自動的にスケールを動かしてくれます。コンテナを最適化する必要があるアプリケーション構成においても疎を強制される、すなわち規律ができます。先程出した「禁欲」というワードにも関連しますが、何もかも一つのアプリケーションではできません。一つの目的をうまくこなすような規律が生まれたのは、運用面でのメリットでした。 スタートアップ企業や成長中のエンジニアによくあることですが、現在は組織のあり方が変わってきて、人材は高コスト化する一方、一つの組織に滞在する期間は2年にも満たないケースが多い。流動性が高い中では宣言的アーキテクチャが求められますが、Kubernetesは最適な存在だと感じました。「一つのことをちゃんとやる」、UNIX哲学ですね。

逆に辛かった部分は、冒頭でお話したスタートアップキメラプロダクトを一度解体しなければならなかったことです。フルスタックなフレームワークを徹底的に刻み、ビルドパイプラインを考え直す発明の工程は非常に辛いです。マイクロサービス自体も完璧ではなく、相互依存している部分があったため、中途半端な状態で解体するとかえって労力が増えるということもわかりました。
また、Continuous Deliveryの決定版がなく、結局GCPのCloudBuildをカスタマイズして使うことになった点は心残りの一つです。

Kubernetesの導入に際して、エンジニアに求められる3つの力

横山:上記のメリット・デメリットを踏まえ、Kubernetesの導入に際して、エンジニア組織に求められる力をまとめると以下のとおりです。

・政治力
・腕力
・オミット力

DevOpsの文脈で考えたときに、Kubernetesはまず正しい理解のもとでコンテナを作成しなければならず、適宜応用・調整する作業が求められます。さらに、各ツールが完璧なものではないため、足りない部分があれば腕力、すなわち技術力で作り直す必要もあります。
オミット力が何かと言えば、「禁欲」にも通じる部分ですが、やりすぎると後々困ってしまう部分を日々考えて、「ここはあまり深入りせず簡単に片付けておこう」といった判断ができることですね。

kubernetes

ChatworkにおけるKubernetesの活用

Kubernetes導入前と導入後の状態が2年間続いているChatwork

坂本:ChatworkはKubernetesを導入して2年と比較的長く運用していますので、具体的にどのようにKubernetesを運用・応用していったのかをメインに話していきたいと思います。
まず、Chatworkは日本初のビジネスチャットとしてリリースした、チャット、タスク管理、ファイル共有、ビデオ通話などを利用できるツールです。2019年4月時点で214,000社に導入されています。私は2017年に入社し、SRE部に所属していています。KubernetesをはじめKafka、HBaseなどEC2でホスティングしているものを見ています。
Kubernetes導入は2016年末頃で、ChatworkがScalaを導入するにあたって、メッセージング部分のリプレイスをする際に採用しました。ECSという選択肢もありましたが、当時はまだライブラリが少なく拡張性が低かったことから、Kubernetesを選んだ形です。選定当時のバージョンは1.3。リリース時点では1.5です。
導入箇所はメッセージング部分のリプレイスのほかには、主にWebhookやOAuthなど新規サービスの部分です。Chatwork全体がKubernetes化したわけではなく、PHPのフロント部分はEC2で動いています。いわば、Kubernetesの導入前と導入後を常に体験している状態です。

HBaseと比較するとトラブルは少なく、安定的な運用が可能

坂本:Kubernetes導入にあたって、致命的なトラブルは思ったよりも無かった、というのが正直なところだったので、メンバーにヒアリングしました。実際に遭遇したのは、ありがちですが導入して2週間経過した頃のworkerのディスク溢れです。原因はコンテナのログのローテーションがきちんとできていなかったことでした。
あとはクラスタの移行時、ステートレスなアプリケーションだと思っていたものが実はステートを持っていたという点も挙げられます。クラスタ内部に依存があったため、移行時の並行稼動のタイミングで不安定になりました。大きなトラブルは以上の2点ほどで、火山と言われるHBaseに比べると安定した運用ができています。

Devへの権限委譲と、ツール運用の負担軽減が導入後の大きな変化

坂本:EC2からKubernetesになって具体的にどうなるのだろう、と思われる方も多いと思いますので、運用を楽にしてくれるツールとともにご紹介したいと思います。
Kubernetes自体はAWSで動かしています。2016年当時、EKSは存在しなかったので、kube-awsというcloudformationでKubernetes on AWSを実現するツールを使用しています。cloud-configやstack-templateなどにある程度触れれば、自分たちである程度改変もできるツールです。
メトリクスはDatadogで、ログはfluentdで取っています。ベタですが、fluentdはkube-fluentd-operator(vmware)というツールがあり、これが非常によくできています。fluentdをconfigmap経由で設定できるほか、stdout以外のログも取得可能です。

また、Datadogでご紹介したいのが以下のライブコンテナ的な便利機能です。

kubernetes

坂本:デフォルトでコンテナの15分毎の状況を把握できるので、たまに使うと非常に便利ですね。 また、Kubernetesは自由にオートスケールしやすいという特徴がありますが、cluster-autoscalerというツールはpodのリソースに基づいてworker nodeをスケールしてくれます。
あとはAWSを使用しているとroleをどうするのかという視点がありますが、kiam(kube2iam)というツールがあり、これによってpodに直接iam roleをつけることができます。あとはfalcoというコンテナ内のプロセス監視ツールも利用しています。最後にご紹介したいのがGuard。Kubernetes自体はユーザーを作ることができませんが、Guardを入れると比較的簡単に認証可能です。
Chatworkではこれらのツールを駆使しながら、コンテンツを運用しています。

Kubernetesを上記のような環境で運用して変わった大きな部分としては、デプロイやロールバックなどをDev側に権限委譲するようになったことが挙げられます。SRE側は基本的な部分を用意して、あとは自由に使ってもらうという形です。
ご紹介したような日々の運用を支えるツールの運用も楽ですね。DatadogやfluentdはEC2で運用していると設定ファイルを持っておくのが面倒だったのですが、Kubernetesはconfigmapだけで運用できるので、システムの負担が減るのがありがたいです。
当社ではあまり使っていませんが、operatorを使うことでそもそもの運用を自動化することもできます。運用が難しいため諸刃の刃ではありますが、うまく使えれば強力だと思います。

学習コストの高さと、バージョンアップのスピードが運用面の難しさ

坂本:逆に運用面で難しい部分もいくつか挙げておきます。先程Dev側に権限委譲しているとお伝えしましたが、そのために学習コストが高くなっているのが問題点の一つです。なかなか技術が広まらず、Kubernetes導入に立ち会っていたKubernetesに詳しい人だけがメインで対応してしまっている状況です。 CI/CDもKubernetes自体が提供している機能でやりやすくはなったものの、ツールは正直言って群雄割拠状態です。Concourse を使用していますが、すべてyamlで書くため2,000行くらいの恐ろしい長さになってしまい、2年運用してもしっくりきていません。 また、必ず直面するのがバージョンアップの壁です。Kubernetesは3ヶ月に1回必ず更新されます。kubeletにもそれなりに変更が入り、そのままローリングアップグレードをすると機能しないなんてことが普通にあるので、追従が大変です。最低でも1年に1回はバージョンアップが必要な状況です。

全アプリケーションのKubernetes化を目指すために検討すべき点

坂本:Chatworkとしての今後の展望は、全アプリケーションのKubernetes化ですね。PHPアプリもデプロイなど動かすものが2種類あると運用コストが高くなりすぎるため、絶賛対応中です。EC2に特化しすぎていた部分、特にnginxまわりもほとんど魔改造に近い状態になっているので、どうKubernetesにまわすのか検討中でもあります。contoroller, etcdを持たなくてよくなるため、EKSへの以降も予定しています。istioなんかはまだまだ使うと思うので、段階的に導入するつもりです。

kubernetes

多数の企業支援を通して見えてくるKubernetes導入のポイント

「Kubernetesが好き≠Kubernetesの機能を全て使いこなす」という前提

寺田:寺田と申します。簡単に自己紹介すると、サン・マイクロシステムズ株式会社、日本オラクル株式会社を経て、3年ほど前に日本Microsoftに参画しました。ずっとJava畑で活動していましたが、現在さまざまな企業の技術的支援、コミュニティ参加、ハッカソンなどを通してKubernetes導入のノウハウなどをお伝えしています。
先日、オイシックス・ラ・大地株式会社がKubernetes上でサービス基盤のマイクロサービス化を決定し、Azureの採用をリリースしていましたが、実際に私が一週間張り付いて、ソースコードを見ながらマイグレーションのお手伝いをしたものです。
恐らく会場にいるみなさんのうち、Kubernetesと聞いてAzureを最初にイメージされる方は少ないと思います。オイシックスさんも同じで、最初はGCP、もしくはAWSを考えていましたが、検討を重ねて最終的にAKS(Azure Kubernetes Service)化を決定された形です。

このように企業支援を行う中でさまざまな事例に触れてきましたが、「なんのためのKubernetesなのか」をきちんと考えているかそうでないかでお客様は二極化します。「なんのために」というよりもKubernetesが好き、触りたいというモチベーションがある方は多いと思いますし、私もKubernetesは好きです。しかし、だからといって嫌なところ、使いにくいところは触る必要はありません。プロダクトに合わせて良い部分を適材適所で使っていくべきだと考えています。
また、ハッカソンなどで必ずお伝えしているのが、「DevとOpsの方、必ず両方で来てほしい」ということです。KubernetesはDevのツールでもないし、Opsのツールでもありません。両者が協力してはじめて使いこなせるものです。また、Dev側にはOps側の、Ops側にはDev側の知識を知っていることが非常に重要です。

kubernetes

Kubernetes導入に必要なのは事例ではなく、「小さな失敗」を重ねる覚悟

寺田:Kubernetesには向き不向きがあります。スケールアウトできるようなアプリケーションはKubernetes向きですね。また、変更に強いアプリケーションもkubernetesは得意です。マイクロサービスもそうです。アプリケーションをどんどんバージョンアップしていきたい、もしくは既存のアプリケーションにいろいろなアプリケーションを追加していきたい、あるいは追加していける、変更に強いシステムにKubernetesはぴったりです。
一方、たとえばスケールアップが必要なアプリケーションは向きません。一回作成したらバグ修正しかしないような、昔の基幹系のようなシステムなら、Kubernetesはやめておいた方がいいでしょう。そのまま昔ながらの構成で運用することをおすすめします。
つまりは適材適所なので、どんなアプリをKubernetesに載せたいのかが導入の重要なポイントです。現在は日本も含め世界中でKubernetesやマイクロサービスの事例が出てきていますし、実際にお客様が「あの会社で上手く導入しているから、うちもやろう」と考えるケースはよくあります。実際、ベンダー側にいても事例を求められます。ですが、他の会社で成功しているからといって、技術レベルもノウハウも全く異なる自社で同じことができるとは限りません。まずは小さい失敗をしながら学んでいくことしかKubernetesはできないと思います。
その中で私が提案しているのは、まず少数精鋭のチームを作ること。そこでKubernetesを試して、徐々に規模を広げていくのが比較的リスクの低い方法と言えます。

Kubernetesに対して盲目にならず、あくまで「道具」として扱うための思考が大切

寺田:先程適材適所とお伝えしたとおり、Kubernetesに対して盲目にならないでほしいとも思っています。
Kubernetesはあくまで道具ですから、Kubernetes以外の選択肢でより簡単にできる方法があるのなら、積極的に検討すべきです。たとえばMicrosoftにはKubernetes以外にもコンテナを動かすWeb App for Containersというものがあります。これはPaaSで提供しているもので、AKSに比べたら圧倒的に教育コストがかかりませんし、スケールも簡単です。もっと言えば、サーバーレスが向くのであれば当然視野に入れるべきです。
Kubernetesは3ヶ月に1回という頻度でアップデートしていきますし、エコシステムも速いスピードで広がっています。ですが、すべてをKubernetesでやろうとすると非常に苦労するのです。Kubernetesの便利な一部の機能だけを使いこなせば充分だということを念頭に、Kubernetesを道具としてどう使うのかを検討していくべきでしょう。

海外の最新情報をどれくらいキャッチできるかがKubernetes導入の明暗を分ける

寺田:以上を前提として、Kubernetesを導入する前に準備すべきこともたくさんあります。当然、サービスを改善したいのであればまずは現状の課題を洗い出すことが必要です。バリューストリームマッピングでもいいでしょう。何にどれだけ時間がかかっているのかを整理して、一つずつ改善していく。その結果としてKubernetesを導入することで将来的に良いシステムが出来上がるのであって、いきなりKubernetesを使おう、という話にはならないはずです。たとえばまずはテストコードの自動化からやっていくといった形でも構わないと思います。
最後のメッセージとして、新しい技術に触る際はさまざまなトラブルに遭遇するということも踏まえておいてほしいと思います。Kubernetesは自分たちで育てていくシステムでもありますから、その途上で絶対にトラブルが起きますし、躓くこともあります。
その際に重要になるのは、実は英語力です。英語力の差が技術力の差になると言ってもいい。Kubernetesの情報を検索したとき、日本語の情報は大抵古くなっています。最新の情報にあたるなら、必ず英語の本家のサイトをチェックしなければなりません。さらにスタックオーバーフローやGitHubのIssuesを見に行くといったことができないと、Kubernetesは触れないと思います。

後編のパネルディスカッションに続きます>>
【後編】~CDはどうすべき?DevとOpsの関係は変化する?気になるポイントを徹底議論~


この記事を書いた人
flexy編集部
flexy編集部
ハイスキルIT人材への案件紹介サービス
サーキュレーションが運営するフリーランスのエンジニアを中心としたIT人材の案件紹介サービスflexy。エンジニアに役立つコンテンツも提供しています。【flexyのサービス詳細】★求人を募集している法人様向けお仕事をしたいご登録希望の個人様向け

週1日~/リモートの案件に興味はありませんか?

週1日~/リモートの関わり方で、「開発案件」や「企業のIT化や設計のアドバザリーなどの技術顧問案件」を受けてみませんか?副業をしたい、独立して個人で仕事を受けたエンジニア・デザイナー・PM・技術顧問の皆様のお仕事探し支援サービスがあります。

flexyでご案内できる業務委託案件

業務委託契約・開発案件(JavaScriptメイン)

テーマ flexy登録画面から案件詳細の確認と直接応募が可能です
勤務日数 2-3日/週
報酬 4万円/日
必要スキル JavaScript・React
勤務地 東京都内/リモート含む
リモート

外部CTO、技術顧問

テーマ 技術アドバイザリーとして知見と経験を生かす
勤務日数 1日/週
報酬 10万円/日
必要スキル エンジニア組織立ち上げや統括のご経験、コードレビュー経験、技術的なアドバイスが出来る方
勤務地 東京
リモート 相談可

業務委託契約・インフラエンジニア

テーマ flexy登録画面から案件詳細の確認と直接応募が可能です
勤務日数 2-3日/週
報酬 5万円/日
必要スキル それぞれの案件により異なります
勤務地 東京
リモート 相談可

業務委託・フロントエンドエンジニア

テーマ flexy登録画面から案件詳細の確認と直接応募が可能です
勤務日数 週1日〜
報酬 5万/日
必要スキル それぞれの案件により異なります
勤務地 東京
リモート リモートと常駐のMIXなど

人材紹介のCTO案件(非公開求人)

テーマ CTO、技術顧問案件はflexyに登録後、案件をコンサルタントからご紹介します
勤務日数 業務委託から人材紹介への移行
報酬 年収800万以上
必要スキル CTOとして活躍可能な方、エンジニア組織のマネージメント経験
勤務地 東京
リモート 最初は業務委託契約で週3日などご要望に合わせます

業務委託契約・サーバサイドエンジニア

テーマ flexy登録画面から案件詳細の確認と直接応募が可能です
勤務日数 週2-3日
報酬 案件により異なります
必要スキル 案件により異なります
勤務地 東京都内
リモート 相談可能
個人登録

お仕事をお探しの方(無料登録)
法人の方(IT課題の相談)