Zenn
🧭

この1年でインフラ担当としてやったこと その3

2021/12/18に公開
Kubernetes
インフラ
Istio
tech

この記事は「イエソド アウトプット筋 トレーニング Advent Calendar 2021」18日目の記事です。

この記事は前回の続きとなります。

Istioの導入

弊社が使っているのはGKEですが、Istio on GKEではなく自分たちでインストールをして管理をしています。理由としては、導入時はまだbeta段階であったこととネットワーク周りのツールはバージョン管理を自分たちで行っていく方が、安定につながると考えたからです。
Istioの導入についてはIstioOperatorファイルを生成して、それをスクリプトで各環境にインストールする形をとっています。IstioOperatorでは、pilotとingressGatewaysのリソースやHPAの設定と、アクセスログフォーマットとエンコーディングの設定、及びトレーシングの設定をしています。トレーシングについては現状あまり活用はできていませんが、zipkin-gcpを使用してCloud Traceに流し込んでいます。
Google-managedの証明書を使用したかった点とIAPを活用したかった点から、GCLB=> Ingress Gateway => 各service Podというネットワーク構成で構築をすることにしました。GCLBのbackendとしてingress Gatewayを使用する場合の注意点として、healthCheckが一点あります。GCLBはbackendに対してのhealthCheckを常に行っており、healthcCheckに失敗をすると当たり前ですが、backendにアクセスすることはできなくなります。さて、IngressGatewayのhealthCheckをどのようにするかという点についてですが、IngressGatewayにはヘルスチェック用の応答ポートとエンドポイントが用意されています。つまり、GCLBのヘルスチェックからきたリクエストだけは、IngressGatwayのヘルスチェックポートに対してリダイレクトをするように設定をしてあげれば解決します。
リダイレクトの設定についてはVirtualServiceを使用します。

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: health
spec:
  gateways:
    - gateway
  hosts:
    - "*"
  http:
    - match:
        - headers:
            user-agent:
              prefix: GoogleHC
          method:
            exact: GET
          uri:
            exact: /
      rewrite:
        authority: ingressgateway.istio-system.svc.cluster.local:15021
        uri: /healthz/ready
      route:
        - destination:
            host: ingressgateway.istio-system.svc.cluster.local
            port:
              number: 15021

GCLBからのリクエストはUAにprefixとしてGoogleHCが付与されていますので、そのヘッダーが付与されたリクエストは全て、自身のPodのhealthCheckエンドポイントにリダイレクトするように設定をします。これによって、IngressGatewayのhealtchCheckを行うことができます。

rate limitの設定

IStioを導入したのでrate limit関連の設定も併せて行いました。ちょうど導入したタイミングが、Istio内でのrate limit設定方法は全てenvoyのrate limit機能を使用して行うように切り替わっているところだったので当時は公式ドキュメントにも方法が書いておらずかなり困惑した記憶があります。今は公式に設定用のドキュメントがあるので興味がある方はこちらを参考にしてください。
cookieの情報をもとにrate limitをしたいという要望もあって、header to metadata filterとmatadataを使用したrate limit actionの合わせ技で実現しました。

コスト改善のために本番環境以外をオンデマンドとプリエンプティブルノードとのハイブリッドにするように

その1の時に少し書いたのですが、環境が増えたことによりコストの上昇が目立つようになってきました。コストの詳細を見るとやはり、Compute Engineにかかるお金がほとんどで、これはまずいと思いプリエンプティブルノードをクラスターの中に混ぜるようにしました。Node Affinityの設定でIngress GatewayやIstiod、営業がデモで使用するアプリケーションPodは優先的にオンデマンドインスタンスに配置させるように設定をしました。その結果もあり、コストは下がったのですが、今後はHPAのバージョン2を活用して土日や深夜など社員が利用する可能性が低い時間帯や日程はPodの数を少なめに設定するなどの、スケジュールベースのスケーリングを入れていきたいなと考えています。

チーム内での取り組みとしてキャパシティプランニングを隔週で実施

Prometheus,LokiやGrafanaなどの導入により、ある程度のアプリケーションメトリクスをGUI上で確認することができるようになったこともあり数ヶ月前から、エンジニアメンバー全員で各メトリクスを確認して、問題ないかの確認や、次やるべきアクションを決めるキャパシティプランニング会を隔週で実施するようにしました。分析と改善を主の目的として置いていますが、副作用的にエンジニアメンバー全員にインフラ構成のナレッジ共有にもなっており、今後も継続して行っていく予定です。

最後に

この1年インフラ担当として、やってきたことを書いてきましたがまだまだやることはあります。
来年もこのタイミングで一つの振り返りとして色々と改善したことを書いていきたいなーという思いです。

Discussion