3社の事例に見るKubernetes導入経緯と共通点、運用上のポイントとは
※本記事は2019年5月に公開された内容です。
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がもたらすものを要点として２つお伝えしたいと思います。
- 現代のトータルエンジニアリングカオスの規律化
- リポジトリ構成、デプロイフローが複雑化
特に、リポジトリ構成、デプロイフローの複雑化という面で、株式会社ZEALSの「会話広告fanp」というChatBotサービスを事例としてご紹介します。LINEやFacebook広告のリンク先をボットに設定し、ユーザーとの会話を通して商品・サービスを提案、コンバージョンを獲得することが可能なものです。先日藤田ファンドらから3.5億円の資金調達も実施して急成長しています。
Kubernetesの導入理由は具体的に2つ。
まず、サービスが複数のマイクロサービスによって構成されていて、お互いの信頼性を確保しようとしたときに、コンテナオーケストレーション環境は非常に相性が良かったというのが一つ。
二つ目は組織的、人的な要因です。インフラやサーバー、フロントといった横軸でエンジニアを分けるよりも、垂直にオーナーシップを持つ方がエンジニアは成長しやすく、長期的にもいいだろうと考えました。Kubernetesを導入してからはAzureをGCPに入れるクラウド移行も含めて5ヶ月ほど経過しています。パート職員も含めて2～3名のメンバーで移行作業中です。
簡単に構成をご紹介すると、すべてをKubernetesにするのではなく、GCPのマネージドサービスを積極的に使っている形です。
横山：
ChatBotらしくPub/Subメッセージングが主流になるサービスのため、マイクロサービスと非常に相性がいいのです。マイクロサービスは管理PF、Sub、Pub、Browser manipulatorの4つです。Kubernetes自体はさほど難しいことはしていません。
細かな利用技術について、オーケストレーションはもちろんKubernetes。コンテナはDocker、マニフェストはKustomizeで生成しています。暗号はkubesec＋Cloud KMS。CDに関してはCloudBuildで、監視ツールはDatadogです。
Kubernetesは現在の高コストで流動性が高いエンジニア組織の性質にもマッチする
横山：
導入して良かった点は自律化です。オートヒーリングですね。自動的にスケールを動かしてくれます。コンテナを最適化する必要があるアプリケーション構成においても疎を強制される、すなわち規律ができます。先程出した「禁欲」というワードにも関連しますが、何もかも一つのアプリケーションではできません。一つの目的をうまくこなすような規律が生まれたのは、運用面でのメリットでした。
スタートアップ企業や成長中のエンジニアによくあることですが、現在は組織のあり方が変わってきて、人材は高コスト化する一方、一つの組織に滞在する期間は２年にも満たないケースが多い。流動性が高い中では宣言的アーキテクチャが求められますが、Kubernetesは最適な存在だと感じました。「一つのことをちゃんとやる」、UNIX哲学ですね。
逆に辛かった部分は、冒頭でお話したスタートアップキメラプロダクトを一度解体しなければならなかったことです。フルスタックなフレームワークを徹底的に刻み、ビルドパイプラインを考え直す発明の工程は非常に辛いです。マイクロサービス自体も完璧ではなく、相互依存している部分があったため、中途半端な状態で解体するとかえって労力が増えるということもわかりました。また、Continuous Deliveryの決定版がなく、結局GCPのCloudBuildをカスタマイズして使うことになった点は心残りの一つです。
Kubernetesの導入に際して、エンジニアに求められる3つの力
横山：
上記のメリット・デメリットを踏まえ、Kubernetesの導入に際して、エンジニア組織に求められる力をまとめると以下のとおりです。
- 政治力
- 腕力
- オミット力
DevOpsの文脈で考えたときに、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のディスク溢れです。原因はコンテナのログのローテーションがきちんとできていなかったことでした。あとはクラスタの移行時、ステートレスなアプリケーションだと思っていたものが実はステートを持っていたという点も挙げられます。クラスタ内部に依存があったため、移行時の並行稼動のタイミングで不安定になりました。大きなトラブルは以上の２点ほどで、火山と言われる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でご紹介したいのが以下のライブコンテナ的な便利機能です。
坂本：
デフォルトでコンテナの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の機能を全て使いこなす」という前提
寺田：
寺田と申します。簡単に自己紹介すると、サン・マイクロシステムズ株式会社、日本オラクル株式会社を経て、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以外の選択肢でより簡単にできる方法があるのなら、積極的に検討すべきです。たとえばMicrosoftにはKubernetes以外にもコンテナを動かすWeb App for Containersというものがあります。これはPaaSで提供しているもので、AKSに比べたら圧倒的に教育コストがかかりませんし、スケールも簡単です。もっと言えば、サーバーレスが向くのであれば当然視野に入れるべきです。
Kubernetesは3ヶ月に1回という頻度でアップデートしていきますし、エコシステムも速いスピードで広がっています。ですが、すべてをKubernetesでやろうとすると非常に苦労するのです。Kubernetesの便利な一部の機能だけを使いこなせば充分だということを念頭に、Kubernetesを道具としてどう使うのかを検討していくべきでしょう。
海外の最新情報をどれくらいキャッチできるかがKubernetes導入の明暗を分ける
寺田：
以上を前提として、Kubernetesを導入する前に準備すべきこともたくさんあります。当然、サービスを改善したいのであればまずは現状の課題を洗い出すことが必要です。バリューストリームマッピングでもいいでしょう。何にどれだけ時間がかかっているのかを整理して、一つずつ改善していく。その結果としてKubernetesを導入することで将来的に良いシステムが出来上がるのであって、いきなりKubernetesを使おう、という話にはならないはずです。たとえばまずはテストコードの自動化からやっていくといった形でも構わないと思います。
最後のメッセージとして、新しい技術に触る際はさまざまなトラブルに遭遇するということも踏まえておいてほしいと思います。Kubernetesは自分たちで育てていくシステムでもありますから、その途上で絶対にトラブルが起きますし、躓くこともあります。その際に重要になるのは、実は英語力です。英語力の差が技術力の差になると言ってもいい。Kubernetesの情報を検索したとき、日本語の情報は大抵古くなっています。最新の情報にあたるなら、必ず英語の本家のサイトをチェックしなければなりません。さらにスタックオーバーフローやGitHubのIssuesを見に行くといったことができないと、Kubernetesは触れないと思います。
３者のLTを通して考える、Kubernetes導入の共通点とは
横山：
ここからは私がファシリテーターを務めさせていただきますので、よろしくお願いします。みなさん発表された内容はそれぞれロール、視点が別れていた反面、導入に際して苦労した部分では共通点も多くありました。まずはお互いのLTを聞いた感想から聞いていきたいと思いますが、いかがでしたか？
坂本：
Kubernetesは周辺も含めて成長が早くツールもさまざま登場しているので、横山さんの事例とChatworkとでは使用ツールが全く違うのが面白いですね。その一方でKubernetesは寺田さんがおっしゃったとおり適材適所の技術ですし、現場に変化をもたらしていくという目的にフィットするという点は概ね同意できます。
寺田：
実際Kubernetesに触っているとみなさん苦労される点が必ずあって、それを乗り越えてここにいらっしゃるのだなと強く感じました。私自身の発表でも述べた点ですが、Kubernetesのいいところを上手に使っているはずです。
技術的にそのとおりだと思ったのは、ローリングアップグレードについてです。私もクライアントにお伝えしているのですが、Kubernetesを提供しているプロバイダから「うちはローリングアップグレードの機能があるのでボタン一つでバージョンアップできますよ」と言われても、絶対にやめた方がいいですね。壊れる可能性があります。
バージョンアップするのであれば今あるクラスタはそのまま残しておいて、新しいバージョンでクラスタをもう一つ作った方がいいでしょう。既存の設定をそちらにすべて移行して、上手くいったのを確認してからフロント側でルーティングを切り替える。そちらの方が安全ですし、何か問題があれば戻せばいいだけですから。ローリングアップグレードをして壊れたら、もう元に戻せません。このようにクラスタを容易に作成したり破棄できるようにするためには、１つのクラスタで大規模なノードを構成しない方が良いでしょう。大規模なクラスタを作る事、例えば、１クラスタで 100 ノードを管理するようなクラスタを作るというのは、k8s クラスタで新たにモノリシックを作っているのと同じ事を意味しています。
【ご登壇者：Chatwork株式会社 坂本諒さん】
CD事情はKubernetes運用において苦労する要素の一つ
横山：
さきほどLTが終わったあと、3人の間でCDが大変だという話題が出たのですが、具体的な大変さや、逆にこんなCDなら許せるといったことはありますか？
坂本：
最近うちのチームではgitopsがいいのではと話しています。うちは今CIOpsにConcourseを使っているのですが、CIOpsの問題でKubernetesに接続しないため、credentialをどう持たせるのかが大きな悩みです。GitOpsなら中にエージェントを入れてGitの方を監視してマージにフックしてデプロイすることが基本になりますし、接続の問題もなくなりますし、全てGitにあるという状態になりますね。
横山：
algoCDは触りましたか？
坂本：
触ってないですね。
横山：
あれは絶賛開発中のようですね。しばらく更新が止まっていたのですが、最近また動きはじめたので期待しています。GitOpsだと複数のリポジトリの管理や各環境の差異をどうするかを考慮する必要があり正しく管理するのは大変そうですね。
坂本：
悩ましいところですね。当社はHelmを使っているのですが、今まではアプリケーションだけリポジトリしていれば良かったものが、今はDockerで切って、アプリで切って、さらにHelmで切らないと連携しづらくなりました。
Kubernetes自体がデプロイメントの仕組みを持っているので手動でできないこともないのですが、そうなると今度は管理の問題が出てくるため、避けたいところです。全て管理画面やgitとの連携などがスムーズにできるCI/CDを模索しています。
横山：
寺田さんはちらっとAzureについて言及されていましたね。
寺田：
ずっとAWSを利用してきたお客様がいて、PHPのアプリケーションをKubernetesに載せる支援をしたのですが、その際にご紹介したのがAzure DevOpsというツールです。旧名はVisual Studio Team Services（VSTS）。これはSaaSのサービスで、Team Foundation Serverから移行したものです。
私自身、VSTSはMicrosoftに入社するまでは存在を知りませんでしたし、Java畑の人間だったこともあり、C#のことしか考えていないものだろうと思っていたのですが、CI/CDが非常に便利でした。Azure DevOps単体で使えますから、これでCI/CDを行い、デプロイ先としてAWSやGCPを利用することもできます。
通常なら一つずつ自分でCI/CD環境を作成する必要がありますが、Azure DevOpsを使うとsampleを簡単に作ることができます。ウィザード形式で、Javaを使用する、deploy先をKubernetesにするなど条件を選んでページ遷移をすると、それだけでGit、ビルドパイプライン、デプロイパイプライン、さらにKubernetesも作成して、最後にデプロイが完了したらメールが送信されます。
横山：
なるほど。ちなみに当社はCDツールにCGPのサービスであるCloudBuildを使用しています。ビルドステップ自体もコンテナを使うのがユニークで癖が強いですが面白いツールです。あとはSpinnakerやJenkinsXもありますね。
坂本：
Spinnakerはメルカリさんなどが使っていますし、規模の大きいチームにはフィットするのでしょうね。ただ、機能が豊富なものをカバーするアーキテクチャなので非常に重く、小さいチームには難しいと思います。
【写真：左から 日本Microsoft株式会社 シニアクラウドデベロッパーアドボケイト 寺田佳央さん、Chatwork株式会社 坂本諒さん、モデレータの横山哲郎さん】
DevとOpsがお互いの領域に踏み込み、知識を得ることが求められる
横山：
CDにこだわるのは、さきほどの寺田さんのLTにもありましたがOpsだけでなくDevの人も関わってもらわなければならないからです。デプロイが簡単にできれば、DevのKubernetesに対するハードルも高すぎずに済む。とはいえソフトウェア開発を徹底的に学ぼうと思ったならDevでもKubernetesの敷居の高い部分を学んだほうがいいとも考えられます。いかがでしょうか？
寺田：
私自身はバックグラウンドとして大学時代にUnixやLinuxに触れてきましたし、その後Javaを学びました。私たちはたまたまそういう経験の重ね方をしてきましたが、今の方にそれができるかというと難しい部分もあります。
その点で私がすごいと思ったのは、NAVITIMEさんの取り組みで、Devはインフラに、インフラはDevにジョブローテーションするというものです。その効果として、それまではDev側が「インフラなんて…」と思っていた部分や、逆にインフラ側が「自分はインフラ側しかわからないから」と思考停止していた部分が解消され、逆にDev側がインフラをやりたい、インフラ側がDevをやりたいと思うようになるなど、良いエンジニアサイクルが回っているそうです。
会社の取り組みが無い場合は自分自身で成長を促すことになります。ただ、自分にインフラ知識が足りないならそちらに積極的に手を伸ばすといったことをしていかないと、今後10年生き残れないのかなとも思います。
坂本：
ChatworkでSRE的な取り組みができているかというと、正直まだまだ不足しています。SREもGoogleだからできることで、そこまでの体力は無いのが正直なところです。
基本的なSREの方針として考えているのは、プラットフォームを準備するということです。Dev側にDevOpsをすべて任せるのは無理な話なので、どうやったら使いやすくなるのかを吟味し、やりたい内容を実現するための環境を用意するのもSREの役割です。結局そこは、組織がどう構成されているかも絡んできますね。
横山：
Dev、Opsというよりも、エンドユーザーに対してどうサービスをデリバリーできるのかをKubernetesにしたからこそ考えなければいけませんから、コミュニケーションの仕方も吟味する必要がありますよね。
【モデレータ：横山哲郎さん】
質疑応答
Kubernetesにして後悔したことはありますか？
坂本：
後悔したことはないですね。夜眠れるようになりました。
横山：
寺田さんはお客様が後悔しそうだと予見できるケースがあれば、基準を教えてほしいです。
寺田：
先にコンテナをやりたい、マイクロサービスをやりたい、Kubernetesをやりたい！から入る場合は、危険を察知しますね。これもハッカソンなどでお伝えしていることですが、これからのエンジニアには何にどんな技術が向くのかを見定める力が重要になります。このシステムにKubernetesは向かないから、別の技術を使うべきだとはっきり考え、発言できる人が求められるはずです。盛り上がりに乗っかるのではなく、一度踏みとどまって考えられる人、ですね。
Kubernetesのマニフェスト管理はどうしていますか？
横山：
私の事例で言うと、基本構成やデプロイメントなどの細かい設計部分はインフラ側の役割だと思っています。たとえばDev側がCronJobを一つ入れたいといった場合は自動生成するコマンドを用意して、簡単に新しいマニフェストができるようにしています。エントリーポイントをDev向けに置いておくということです。
坂本：
うちの場合は基本的にHelmを使っていますが、Helmチャートの場合はクラスタを運用する上で必要なものはSREが管理して、アプリに関してはほぼDev側に任せています。
寺田：
1つのサービスに対してソースコードと必要なDockerファイルやyamlを1つのリポジトリにまとめています。別にすると、私の場合どこに置いたのか忘れてしまうので。
学習・運用コストが高く、人材難易度が高い中でKubernetesを導入している理由は？
横山：
確かにKubernetesに触れている人材は市場に多くないので、獲得したいのは学ぶ意欲のある人ですね。技術自体は難しいものの、がんばればなんとかなるレベルです。
坂本：
Kubernetes自体が比較的新しいアーキテクチャで整理されていますから、少なくともHBaseに比べればわかりやすいと思います。
寺田：
Java畑の人間にしてみると、Enterprise JavaとKubernetesはそっくりです。今まで培ってきたノウハウをそのままKubernetesでも利用できるので、今までJavaのアプリ側をやっていたものがコンテナ側に変わっただけという感覚が強いですね。
コンテナ監視はどうしていますか？
横山：
autodiscoveryがついていないと始まらないので、選択肢はDatadogかPrometheusになりますね。
坂本：
Prometheusの方が拡張性は圧倒的に高いものの、その分自分たちで調整してなんとかする必要があります。Datadogの方はお金さえ払えばDatadog側がモニタリングしてくれますし、安定しているので基本的な部分は抑えられると思います。DatadogでもPrometheusのexporterからデータを取り込むことは可能なので、Prometheusにしか対応していない場合アプリケーションでも利用することは可能です。
横山：
Azureの場合はどうでしょう？
寺田：
インストール時に監視用のエージェントをつけることができます。AKSの売りの一つですね。特に海外のお客様に多いのが、自分たちはサービスの開発に集中したいという要望だからです。Prometheusを使うにしてもログのボリュームをどう管理するかなど手間がかかりますから、忌避する方が多い。AKSはそこをマネージド側で引き取る形にして、ロジックの開発に集中できるようにしています。Prometheusなどでできることは大体ポータル上でできるイメージです。
アプリデベロッパーがコンテナ技術に無関心です。どうしたらいいでしょうか？
寺田：
企業向けにモチベーションアップの話もさせていただくことがありますが、今後はエンジニアとしてどう成長したいのかに気づくエンジニアとそうではないエンジニアで、はっきりと差が出てくるはずだとお伝えしています。給与格差も生まれます。私自身、知り合いの社長さんには年齢や性別は関係なく、思い切り給料の差をつけるべきだとお伝えしています。そうしないと変わっていきませんから。
横山：
日々新しい技術がたくさん登場する中で。すべてキャッチアップするのは無理です。ただ標準化が入るなど、潮目が変わる瞬間はあります。Kubernetesは去年潮目が変わりました。Cloud Native Computing Foundation」（CNCF）がKubernetesを卒業プロジェクト（Graduated Project）に認定して、今後長年にわたってサポートされる技術だという趨勢が決まりました。プロダクトのすべてに導入するかは吟味の必要があるとはいえ、今後の技術の中心になってくるはずですから、勉強をして絶対に損はしない技術だという点は押さえておくべきでしょう。
FLEXYのご紹介
FLEXYは、エンジニア、技術顧問、CTO、デザイナーの方向けに案件をご紹介するサービスです。
リモートワークや週1-5日、高単価案件など、ご希望に合った案件をご紹介いたしますので、是非お気軽にご相談ください。
■関連記事：
