OperationCodeでのKubernetesインフラストラクチャのリファクタリング（前半）

OperationCodeでのKubernetesインフラストラクチャのリファクタリングに関する記事です。長い記事なので前半と後半に分けてお送りします。

Kubernetes インフラをより良い状態にして、その過程でAWSの請求額の3分の2を削減するという話はここから始まりました…

Nell Shamrell氏は#infrastructure-teamチャンネルで、私たちの毎月のAWSの請求額が非常に高いことを指摘しました。正直に言えば、OperationCodeのような組織にとってはとても高額だというのです。

私は約1年前からOperationCodeでオペレーション作業を手伝ってきましたが、Kubernetes (k8s) クラスタにはかなりの作業が必要でした。

1. それはまだKubernetes 1.11（21ヶ月前のもの！k8sで言えば百年前と同じ）上でのアップグレードするための手順は危険を伴うものだった。

2. Google認証とsecrets.jsonファイルを含む面倒なオンボーディングのユーザー登録プロセスがあり、誰もが(管理者も含めて！)失い続けていた。

3. 6x t3.mediumインスタンス（マスター3台、ワーカーノード3台）、3つのNATゲートウェイ（これは驚くほど高額！）、そしてとてつもなく大きなEBSボリューム（ホストあたり200GB）で構成されており、ものすごい経費がかかっていた。

ご覧のように、私たちのような小さな組織では、このような経費があっと言う間に増えていきました。

Part 0: Implement Monitoring and Observability

変更を進める前に、監視状況をよく見てみました。アプリケーションのエラーを通知してくれるSentry.io と、メトリクスを取得してKubernetesクラスタ内からアラートを送信するための AlertManager付きPrometheusがあります。

さらに、私は可視性の2つの外部（および無料）ポイントを追加しました。

・ Honeycomb.io から、観測性の計測器、無料のコミュニティプランを利用して500MBのストレージと15/GBのテレメトリデータのインジェストを提供してくれました。バックエンドアプリケーションでPython Beelineを実装するのは比較的簡単で、実際、ほとんどの作業はビルドの修正、ディペンデンシーやドキュメントのアップデート関連のものでした。