いまさらだけど振り返る、Kubernetesを使用して感じた良い点・悪い点
はじめに
もう4年以上も前の話になりますが、とあるレコメンドAPIを仮想マシン環境からKubernetes（K8s）へ移管をしました。
その際に感じた、K8sの良かった点・悪かった点で感じた部分があるため、記事にします。
Kubernetesをこれから使用しようか迷っている人向けに少しでも参考になればと思います。
K8s を導入・運用してみて良かった点
ここでは、Kubernetesを使って「便利だった」「助かった」と感じたポイントを紹介します。
1. 自動復旧
仮想マシン運用では、アプリケーションの停止を監視して手動で再起動する必要がありました。自動化していたとしても、監視ツールの設定や通知、スクリプトによる再起動処理など、実装の手間が大きいのが一般的です。
KubernetesではこれらがDeployment（Kubernetesでアプリを管理する仕組み）の設定だけで完結し、可用性の高いサービスを容易に構築できます。
2. サービスへの影響を最小限にしたデプロイ
仮想マシンの場合は、サーバーを冗長化して、サーバーを1台ずつロードバランサから切り離し、再起動、再接続という作業が発生しました。
KubernetesではPod単位で順次更新・切替が行われるため、この手間が大きく削減されます。
3. リソース調整が容易
VMの場合性質上細かいリソース調整はできません。(例: メモリ4GBを4.5GBにするなど。)また、社内の事情によっては他部署へ増設依頼を出すなどヒューマンコミュニケーションコストが発生するケースもあります。
Kubernetesでは、設定ファイルを変更するだけで即時にスケーリングが可能であり、柔軟なリソース調整も実現できます。
K8s の運用で苦労した点
一方で、運用してみると「これは大変だった」と感じる部分もありました。代表的なものを紹介します。
1. 学習コストが高い
K8sそのものの概念やリソース構成、Networkingの仕組みなどを理解するのに時間がかかります。
また、dockerを使ったことがあるエンジニアにとっても、K8s特有の設定や用語（Pod, Deployment, Service, Ingress, etc.）を覚える必要があるため、最初のハードルは低くありません。
2. ログやデータの保存
コンテナは基本的にステートレス（データが永続化されない）なため、Pod（コンテナの実行単位）が再作成されるたびにコンテナ内部のファイルは消えてしまいます。
ログやデータベースファイルを長期的に保存するには、外部ストレージとの連携やログ集約基盤が必須となります。
対策としては、Fluentd（ログ収集用のツール）などで、各コンテナから出力されるログを別サーバへ転送・保存する仕組みを作る必要があります。
この仕組みの構築や学習コストも思いのほか時間が取られます。
どのようなシステムに K8s が向いているか
必須条件としては、長期的に運用予定があるシステムであることだと感じました。
短期的な運用の場合、初期学習コストが高くなってしまうので向かないように思います。
また、ログの保存の仕組みを構築するのも非常に面倒なので、コストメリットが低いと思われます。
上記に加えて、以下の条件があるシステムが向いていそうです。
- アプリケーションの更新頻度が多いシステム
→ 更新作業を行ってもサービスを止めずに、新しいバージョンに切り替えていくことができます。作業を自動化しやすく、手動よりもすばやく、かつ安全に変更を反映させることができます。 - サービスの成長に伴い、リソースの調整が予測されるシステム
→ 利用者が増えたときなどに、必要に応じてPodの数を増やすなど、柔軟に対応できます。
まとめ
以上です。
ここ数年Kubernetesから離れていましたが、再度触れる機会ができそうなので、一番最初に触った頃の気持ちを思い出そうと思いこの記事を書きました。
これからKubernetesの導入を検討する方は、ぜひ運用期間の長さ・導入目的・チームの学習リソースを踏まえて、採用の可否を判断してみてください。
Discussion