はじめに

こんにちは！株式会社80&Companyの技術広報です。
弊社の開発部署では毎週火曜日の朝9:30から社内勉強会を行なっています。

今回の記事はSRE業務を行なっているエンジニアが社内勉強会でKubernetesについて発表したものを紹介します。SREを簡単に説明すると、Google社が提唱・実践した概念で、「サイト・リライアビリティ・エンジニア（Site Reliability Engineer）」の略称です。サービスやプロダクトの信頼性の向上を図り、エンジニアが開発と運用の両方に携わることによって自動化・効率化し、企業の課題を解決する役割と言われています。

SREエンジニアが発表したKubernetesについて、興味のある方は参考にしてみて下さい♪

読者の対象

Kubernetesに興味がある方
Kubernetesの導入を検討している方
コンテナに対する前提知識のある方

テーマ選定の理由

発表者がKubernetesについて発表した理由としては、
Kubernetesに関して下記のメリット2点を魅力的に感じたからです。

自動化する範囲を大きくすることができる
- アプリケーションのトラフィックに応じて、自動的にコンテナインスタンスを増やすことができる
- アプリケーションのデプロイ、アップデート、およびロールバックを自動化し、アプリケーションが停止しないようにすることができる
- アプリケーションの依存関係を自動的に解決し、必要なコンテナを自動的に配備する
- アプリケーションが異常終了した場合に自動的に新しいインスタンスを起動し、異常を修正する
- ステートフルアプリケーションのデータ永続性、移行、および復元を自動化する
kubernetesをベースとしたサービスで可能となる機能が多数ある(CNCFを参照)
- 水平スケール可能なMySQL（Vitess）の実装ができる
- ゼロスケール、パブリッククラウドなしでサーバーレス、イベントドリブンアーキテクチャの実装ができる

そもそもインフラに求められる機能とは？

インフラに求められる機能としては、大きく可用性、保守性、回復性の3つがあります。

Kubernetesにおいては、インフラに導入することにより、インフラに求められる機能である可用性を実現できます。インフラにおける可用性とは、障害が発生してもサービスそのものへの影響を発生しにくくする能力です。

Kubernetesとは

Kubernetesについて、公式ドキュメントには以下が書いてあります。

Kubernetesは、宣言的な構成管理と自動化を促進し、コンテナ化されたワークロードやサービスを管理するための、ポータブルで拡張性のあるオープンソースのプラットフォームです。Kubernetesは巨大で急速に成長しているエコシステムを備えており、それらのサービス、サポート、ツールは幅広い形で利用可能です。

より分かりやすく例えると「Control Planeに設定ファイルを読み込ませておけばあとは必要なことをだいたい自動でやってくれるサービス」です。

Control Planeはkube-apiserver、etcd、kube-scheduler、kube-controller-manager、cloud-controller-managerといった複数のコンポーネントで形成されています。Control Planeは、Kubernetesの頭脳であり心臓部です。下記の図解のようなオーケストラの指揮者や全社組織図がこれに当たると思っています。意思決定をする一番大きな部分であり、その部分に対して設定できればサービスが動くという仕組みです。

インフラに求められる可用性に対する問題と解決策

インフラに求められる可用性に対する問題とKubernetesの導入による解決策について、
以下の4点が挙げられます。

問題1:ロードバランサー、コンテナの配置など気にする必要性がある

解決策: 複数のリソースを動かしておくことでリソースが壊れてもサービスは止まらないようにする

問題2:イメージ更新の成功、失敗に判定してイメージを更新する必要性がある

解決策: 新しいコンテナが動くことを確認してから古いコンテナの削除を行う

問題3:壊れたイメージを指定したらサービスが止まる時間が発生する

解決策: リソースが壊れたらすぐに新しいリソースを確保する（ダウンタイムを短くする）

問題4:左コンテナが1個で負荷が増えてきた際にレスポンスまでの時間がかかる

解決策: 負荷に応じてリソースを増やす

Kubernetesを導入するデメリット

Kubernetesを導入することによるデメリットについて、以下4点が挙げられます。

学習コストがかかりやすいこと
利用料金がかかりやすいこと
- AWSだと月に70ドルの費用がかかるが、マネージドでないKubernetesの運用は非現実的である
更新対応が多いこと
- 定期的にKubernetesのバージョンがリリースされるため、使用環境のバージョンアップを行う必要がある
物理サーバーの数が増えること
- Kubernetesでは全てのノードに指示を出すための「マスター」が必要であるが、マスターと各ノードは別々の物理サーバーを用いるため、ノードの数に比例して物理サーバーの数も増えていく

補足：紹介できなかったKubernetesのよく使う便利機能

EC2(マシン)単位での自動回復
EC2(マシン)単位での自動スケール
シークレットの保存、設定ファイルでの読み込み

最後に

今回は、弊社社内勉強会で発表されたインフラに求められる機能とkubernetesを用いた解決策について扱いました。今後も継続的に80&Companyでの社内勉強会の取り組みを発信していきます！
Qiita OrganizationやTwitter公式アカウントのフォローもよろしくお願いいたします！
最後まで読んでいただきありがとうございます！

参考文献