Kubernetes(k8s)導入とその後【後編】~CDはどうすべき?DevとOpsの関係は変化する?気になるポイントを徹底議論~

【写真:左から 日本Microsoft株式会社 シニアクラウドデベロッパーアドボケイト 寺田佳央さん、Chatwork株式会社 坂本諒さん、モデレータの横山哲郎さん】

マイクロサービスやDockerの台頭とともに注目度が高まっているKubernetes(k8s)をテーマとして、パネルディスカッション形式で3名のエンジニアにトークしていただきました。Kubernetes導入と運用においてポイントとなる部分を議論、Kubernetes導入を考えているエンジニア必見のレポートです。

前編記事はこちらです>>

3者のLTを通して考える、Kubernetes導入の共通点とは

横山:ここからは私がファシリテーターを務めさせていただきますので、よろしくお願いします。みなさん発表された内容はそれぞれロール、視点が別れていた反面、導入に際して苦労した部分では共通点も多くありました。まずはお互いのLTを聞いた感想から聞いていきたいと思いますが、いかがでしたか?

坂本:Kubernetesは周辺も含めて成長が早くツールもさまざま登場しているので、横山さんの事例とChatworkとでは使用ツールが全く違うのが面白いですね。その一方でKubernetesは寺田さんがおっしゃったとおり適材適所の技術ですし、現場に変化をもたらしていくという目的にフィットするという点は概ね同意できます。

寺田:実際Kubernetesに触っているとみなさん苦労される点が必ずあって、それを乗り越えてここにいらっしゃるのだなと強く感じました。私自身の発表でも述べた点ですが、Kubernetesのいいところを上手に使っているはずです。 技術的にそのとおりだと思ったのは、ローリングアップグレードについてです。私もクライアントにお伝えしているのですが、Kubernetesを提供しているプロバイダから「うちはローリングアップグレードの機能があるのでボタン一つでバージョンアップできますよ」と言われても、絶対にやめた方がいいですね。壊れる可能性があります。 バージョンアップするのであれば今あるクラスタはそのまま残しておいて、新しいバージョンでクラスタをもう一つ作った方がいいでしょう。既存の設定をそちらにすべて移行して、上手くいったのを確認してからフロント側でルーティングを切り替える。そちらの方が安全ですし、何か問題があれば戻せばいいだけですから。ローリングアップグレードをして壊れたら、もう元に戻せません。このようにクラスタを容易に作成したり破棄できるようにするためには、1つのクラスタで大規模なノードを構成しない方が良いでしょう。大規模なクラスタを作る事、例えば、1クラスタで 100 ノードを管理するようなクラスタを作るというのは、k8s クラスタで新たにモノリシックを作っているのと同じ事を意味しています。

kubernetes 【ご登壇者: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はメルカリさんなどが使っていますし、規模の大きいチームにはフィットするのでしょうね。ただ、機能が豊富なものをカバーするアーキテクチャなので非常に重く、小さいチームには難しいと思います。

kubernetes 【写真:左から 日本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は向かないから、別の技術を使うべきだとはっきり考え、発言できる人が求められるはずです。盛り上がりに乗っかるのではなく、一度踏みとどまって考えられる人、ですね。

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編集部
ハイスキル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課題の相談)