2025-01-09

AWS EKS Automode のノード管理について

はじめに

この記事ははてなエンジニア Advent Calendar 2024 2025/1/9の記事です。

昨年の11月にAWS EKS AutoModeが発表されました。AWS EKS AutoMode は、Kubernetes クラスターの管理をより簡単になるよう設計された新しい仕組みです。

Node周りが特徴的だったので記事にしました。

EKS AutoMode の概要

EKS AutoMode は、AWS が提供する便利なクラスター管理機能です。これまでの EKS クラスターと異なり、次の特徴があります。

ノード管理の自動化: ノードプールの作成やスケーリングが Karpenter によって自動的に行われます。
EKS アドオンの自動管理: CoreDNS、kube-proxy、AWS CNI プラグイン、Karpenter、AWS Load Balancer Controller などの主要アドオンが自動で設定・更新され、手動の手間を省きます。

EKS AutoMode クラスターを試してみた

EKS AutoMode を使ってクラスターを作成し、その初期状態や動作を確認しました。

初期状態

クラスターを作成すると、General-purpose と System という2種類のノードプールが用意されています。これらはKarpenterが管理するリソースでコンソール上からはビルトインノードグループとして見えます。初期状態ではどちらのノードプールにもノードがありません。

$ kubectl get nodepool
NAME              NODECLASS   NODES   READY   AGE
general-purpose   default     0       True    2m5s
system            default     0       True    2m5s

当然ながら、ノードがないためPodが1つも動作していない状態です。このことから、Karpenter などの設定済みアドオンはユーザーから直接は見えない場所で動いていることがわかります。

アプリケーションをデプロイしてみる

試しに Nginx を1 Pod デプロイしてみると、Karpenter によって新しいノードがすぐに作成されました。このノードは c5a.4xlarge インスタンスで起動して以下の通りでした。

OS: Bottlerocket
コンテナランタイム: containerd

$ kubectl describe node i-XXXXXXXXXXXXXXXXX
...
System Info:
  OS Image: Bottlerocket (EKS Auto)
  Container Runtime Version: containerd://1.7.22+bottlerocket
  Kubelet Version: v1.31.1-eks-1b3e656
...

このデプロイを削除したらNodeもDrainされ0台の状態に戻りました。

System ノードプールについて

System ノードプールは、クラスター管理用の重要な Pod（例: CoreDNS、kube-proxy、AWS CNI プラグイン）を動かすための専用ノードプールです。このノードプールには、以下のような特徴があります。

専用リソースとしての運用:
- CriticalAddonsOnly というテイントで保護されており、通常のワークロードとは分離されています。
Pod デプロイの条件:
- このノードプールで動作する Pod は、tolerations を設定してテイントを許可する必要があります。

以下のように tolerations を指定することで、System ノードプールでのデプロイを許可できます。

tolerations:
  - key: "CriticalAddonsOnly"
    operator: "Exists"

General-purpose ノードプールについて

General-purpose ノードプールは、主にユーザーのアプリケーションを動かすために用意されたノードプールです。

特徴

柔軟なスケール:
- アプリケーションのリソース要求に応じてノードをスケールアップ・スケールダウンできます
独立したノードプール:
- System ノードプールとは分離されており、アプリケーション優先のスペースとして利用できます
マネージドなインスタンス:
- ノードの作成や更新はすべて AWS によって管理されるため、ユーザーは運用負担を減らすことができそうです
- このインスタンスはマネコンからは見えるのですが SSH や SSM などで接続することはできません

注意点

デフォルトではオンデマンドインスタンスが使われ、特にインスタンスサイズの指定がないため、大きめのインスタンスが起動することもあります。必要に応じて、カスタム設定を行う必要があります。

ノードプールのカスタマイズ

EKS AutoMode では、独自のノードプールを作成することで、スポットインスタンスの利用や特定のインスタンスサイズの指定が可能です。以下は、スポットインスタンス用ノードプールの例です。

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: spot-nodepool
spec:
  template:
    spec:
      requirements:
        - key: "karpenter.sh/capacity-type"
          operator: In
          values: ["spot"]
        - key: "eks.amazonaws.com/instance-category"
          operator: In
          values: ["c", "m", "r"]
  limits:
    cpu: "1000"
    memory: 1000Gi

まとめ

EKS AutoMode を利用することで、以下のメリットが得られます。

簡単なクラスター管理: ノードの作成やスケーリングが自動化され、運用の手間が大幅に減少します。
便利なアドオン管理: CoreDNS や kube-proxy など、主要なアドオンの設定や更新が自動化され、さらなる効率化を実現します。

ビルドインノードグループはインスタンスのキャパシティタイプやインスタンスタイプがデフォルトのため注意が必要です。実際の運用でコスト削減したい場合はカスタムのノードプールを作ることになると思います。

ちなみにビルトインノードグループは初期設定時に構築しないことも可能ですし、一度構築した後も削除できそうでした。

実際の運用に利用できたら運用負荷を下げることができそうなので引き続き検証していきたいと思います。

2023-12-26

EKS Pod Identity を活用するメリット

この記事ははてなエンジニア Advent Calendar 2023 の 26 日目の記事です。本日からはてなエンジニア Advent Calendar 2023 はオーバーランに突入します。昨日は id:d-haru さん明日は id:chaya2z さんとなっています。

私が所属するチームでは EKS を利用してサービスを運用しています。

developer.hatenastaff.com

今年の AWS re:Invent 2023 内でも EKS 関連のアップデートがありましたが、特に EKS Pod Identity という便利な機能に注目したので利用してみました。

EKS Pod Identity とは

EKS を利用者にとって嬉しい機能が発表されました。これまで Pod への IAM 権限の割り振りは IRSA ( IAM Roles for Service Accounts ) を利用するのが一般的でした。Pod に権限を与えるという結果は両者変わらないのですがリソースの管理方法が異なります。

IRSA を利用した場合は以下のような manifest を書くことで kubernetes の ServiceAccount と IAM Role を紐づけていました。

 apiVersion: v1
 kind: ServiceAccount
 metadata:
   name: sample
   annotations:
     eks.amazonaws.com/role-arn: arn:aws:iam::XXXXXXXXXXXX:role/sample-role-arn

ServiceAccount リソースの annotation に IAM Role の Arn を記述しています。manifest に Arn を埋め込むのって面倒ですよね。特に IaC などしている場合、IaC で作成したリソースの Arn をなんとかして埋め込みたくなると思います。

今回、発表された EKS Pod Identity は IAM Role と ServiceAccount の紐づけを kubernetes 側ではなく EKS 側の設定で行うことができるため、IaC との親和性も高く権限管理が簡素化されます。

使い方と解説

アドオンのインストール

コンソールを使った方法は以下のリンクを参照するのが良いと思います。

aws.amazon.com

今回は Terraform を利用した方法で試してみます。

まず、EKS Pod Identity を利用するには eks-auth:AssumeRoleForPodIdentity のポリシーが必要です。事前に Node の Role に AmazonEKSWorkerNodePolicy を利用するかカスタムポリシーでを作成してアタッチしておく必要があります。

EKS Pod Identity は EKS アドオンで追加できるようになっています。 EKS の Terraform module を利用した場合、以下のようにしてアドオンを追加することができます。

module "eks" {
  source  = "terraform-aws-modules/eks/aws"


  cluster_name    = var.cluster_name
  cluster_version = var.cluster_version


  ...
  
  cluster_addons = {
    kube-proxy             = {}
    eks-pod-identity-agent = {}
  } 
}

余談ですが上記に記述しているアドオンの name は以下のコマンドを叩くことで確認することができます。

aws eks describe-addon-versions | grep addonName

さらにアドオンのバージョンやconfigのオプションについても以下のコマンドで確認することができます。

aws eks describe-addon-versions --addon-name eks-pod-identity-agent
aws eks describe-addon-configuration --addon-name eks-pod-identity-agent --addon-version v1.0.0-eksbuild.1

EKS Pod Identity のアドオンを有効にすると kuberntes クラスターの kube-system Namespace に eks-pod-identity-agent が Daemonset としてインストールされエージェントの Pod が起動します。

$ kubectl get daemonset -n kube-system eks-pod-identity-agent
NAME                     DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
eks-pod-identity-agent   1         1         1       1            1           <none>          3d1h

このエージェントは Node に付与した AssumeRoleForPodIdentity のアクションを利用して、一時的な認証情報を取得し、コンテナ内の SDK がその認証情報を利用できるようにします。 Node 側でまとめて認証してくれるので各 Pod 毎に認証をすることがなくなっています。

docs.aws.amazon.com

IAM Role の信頼ポリシー

IRSA ではクラスター毎に OIDC プロバイダーを作成する必要があり、OIDC プロバイダーが EKS と IAM の信頼関係を確率していました。そのためIAM Role に以下のような信頼ポリシーを設定する必要がありました。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::ACCOUNT_ID:oidc-provider/oidc.eks.AWS_REGION.amazonaws.com/id/EXAMPLED539D4633E53DE1B716D3041E"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "oidc.eks.AWS_REGION.amazonaws.com/id/EXAMPLED539D4633E53DE1B716D3041E:sub": "system:serviceaccount:SERVICE_ACCOUNT_NAMESPACE:SERVICE_ACCOUNT_NAME",
          "oidc.eks.AWS_REGION.amazonaws.com/id/EXAMPLED539D4633E53DE1B716D3041E:aud": "sts.amazonaws.com"
        }
      }
    }
  ]
}

クラスター固有の情報が含まれているため、クラスターが増える度に全ての IAM Role の信頼ポリシーを更新する手間が発生していました。

EKS Pod Identity を利用するとその手間は無くなり、OIDC プロバイダーも作成する必要もありません。 IAM Roleの信頼ポリシーは以下を追加すればよくて、固有のクラスター情報を含まないシンプルなものになりました。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "pods.eks.amazonaws.com"
            },
            "Action": [
                "sts:TagSession",
                "sts:AssumeRole"
            ]
        }
    ]
}

クラスターの BlueGreen アップグレード時の IAM Role の更新の手間が減り作業もシンプルになります。

ServiceAccount と IAM Roleの関連付け

kubernetes の ServiceAccount と IAM Role の関連付けについてですが、マネコンから紐づけることもできますが以下の Terraform リソースを利用することで IaC 管理できます。

registry.terraform.io

resource "aws_eks_pod_identity_association" "example" {
  cluster_name    = aws_eks_cluster.example.name
  namespace       = "example"
  service_account = "example-sa"
  role_arn        = aws_iam_role.example.arn
}

Terraform で IAM Role を作成していれば Arn の Attribute を参照することができるので ServiceAccount と IAM Role の関連付けが Terraform 内だけで完結します。もう manifest に Arn を記述する必要はありません。

まとめ

まとめると以下のような設定が必要です。

Node の IAM Role に eks-auth:AssumeRoleForPodIdentity を付与する
EKS Pod Identity アドオンをインストール
IAM Role の信頼ポリシーを EKS Pod Identity に対応したものに設定する
IAM Role と ServiceAccount を関連付ける

上記4点を全て IaC で管理できるので EKS と kubernetes のリソースを独立して管理できます。必要なリソースと内部的な処理も簡略化されているため導入・運用の観点からもこれまでよりも良くなっていると感じました。

2024/01/05 追記

利用しているサービスによっては SDK のバージョンが古く利用できない場合があるため注意が必要でした。secrets-store-csi-driver-provider-aws で利用している SDK のバージョンが v1.47.10 と古いため直近での EKS Pod Identity の利用は見送るつもりです。今後、利用できることを楽しみにしています。

github.com

docs.aws.amazon.com

参考

Amazon EKS が EKS Pod Identity を導入
Amazon EKS Pod Identity simplifies IAM permissions for applications on Amazon EKS clusters | AWS News Blog
EKS Pod Identities - Amazon EKS
🆕 EKS で、Pod に IAM Role を割り当てる新機能として EKS Pod Identity がリリースされました！IAM roles for service accounts (IRSA) と比較して、シンプルに設定することが可能です。 (1/6)https://t.co/WQz4kQVN0m
— Kyosuke Ochimizu (@otty246) 2023年11月28日

2023-07-07

Helmfileを利用して複数のHelm Chartをまとめて管理する

背景

最近、EKSにHelmを使って Opentelemetry Collector をインストールしました。 Opentelemetry Collector で利用するバックエンドプラットフォーム（監視SaaS）のAPIキーが必要になるので AWS Secrets Manager に保管することにしました。

EKSから AWS Secrets Manager のリソースを参照するには Secrets Store CSI Driver の SecretProviderClass というカスタムリソースを作成する必要があります。しかし Opentelemetry Collector のHelm Chart に SecretProviderClass のリソースが存在しないので別途管理する必要がありました。

関連リソースなのでまとめて管理したいと思い調べたところ Helmfile を利用することで解決できそうだったのでやってみました。

Helmfile

HelmfileはHelm Chartをより宣言的に管理できるツールです。Helmのリポジトリなどもコード管理できるようになるのでより再現性を確保することができます。

また複数のHelm Chartを管理できるので、今回のようなカスタムリソースもHelm Chartにしてしまえば一緒に管理できるようになります。

構成

最終的なファイル構成は以下のようになりました。

 ├── helmfile.yaml
 ├── otel-collector
 │   ├── config.yaml
 │   └── helmfile.yaml
 └── otel-collector-misc
     ├── Chart.yaml
     ├── helmfile.yaml
     └── templates
         └── secret-provider-class.yaml

ディレクトリを2つ掘っているのでそれぞれ解説します。

`./otel-collector`

Opentelemetry Collector の Helm Template に渡す変数が書かれた config.yaml を置いています。

helmfile.yaml は以下の通りで Helm Chart の Repository の設定や Release の設定を記述することができます。

repositories:
- name: open-telemetry
  url: https://open-telemetry.github.io/opentelemetry-helm-charts 

releases:
- name: opentelemetry-collector
  namespace: otel-collector
  chart: open-telemetry/opentelemetry-collector 
  version: 0.53.1
  values:
    - config.yaml

`./otel-collector-misc`

SecretProviderClass の簡単な Helm Chart を作成して置いています。 helmfile.yaml には以下のようにカレントのディレクトリを指定するように記述することでローカルの Helm Chart を利用することができます。

releases:
- name: opentelemetry-collector-misc
  namespace: otel-collector
  chart: ./
  version: 0.1.0

`./helmfile.yaml`

./otel-collector と ./otel-collector-misc にある helmfile.yaml へのpathを記述することで複数の Helm Chart を管理できるようになります。

helmfiles:
  - path: ./otel-collector/helmfile.yaml
  - path: ./otel-collector-misc/helmfile.yaml

実行

helmfile apply を実行するだけで Opentelemetry Collector 関連のリソースと SecretProviderClass のカスタムリソースをEKS上にまとめて作成することができました。 helm だと事前に Repository の追加が必要だったり、helm install コマンドに Namespace や Chart のバージョンを渡す必要がありますが、全て helmfile.yaml に記述されているので必要ありません。さらにhelmfile diffで差分を確認できるのも便利ですね。helmの場合はpluginを入れたりする必要があるので。

まとめ

複数のHelm Chartを管理する目的でHelmfileを利用してみましたが、helmfile化することでコード管理できる範囲が広がったことも嬉しいポイントでした。 ArgoCDなどで管理したい場合には Config Management Plugin などを利用すると良さそうなので引き続き試して見ようと思います。

話は変わりますが、先日 Mackerel が OpenTelemetry 対応を進めているといった発表がありました。 API キーの管理方法は今回の件が利用できるかもしれません。こちらも楽しみにしています。

mackerel.io

2022-12-14

EKSクラスターのB/Gアップグレード作業の改善で取り組んでいること

この記事ははてなエンジニアのカレンダー | Advent Calendar 2022 - Qiitaの14日目のエントリです。

背景

私のチームで運用しているEKSクラスターですが、アップグレードはBlueGreenアップグレードする方針をとっています。 B/Gアップグレードを採用している主な理由は切り替え時に問題が発生した場合に素早く切り戻しを行いたいためです。

詳細は以下のブログを参照ください。

developer.hatenastaff.com

B/Gアップグレードのおおまかな流れは以下の通りです。

新バージョンのEKSクラスターを構築する
ArgoCDに新クラスター用のデプロイ設定を手動で作成してアプリケーションをデプロイする
Route53やAWS Global Acceleratorの設定を変更して旧クラスタから新クラスタにリクエストを切り替える

上記の2と3の工程には以下のような課題を感じています。

サービスが増えることで新クラスターに対するデプロイ設定の作業負荷が高くなってきている
より手軽にすばやく切り替え、切り戻しを行えるようにしたい

上記について改善を行ってきたので紹介したいと思います。

実現したいこと

上記の課題より私達が実現したいことは以下の通りです。

クラスタのバージョンアップ時など、デプロイ先のクラスタが増えた場合でも、アプリケーションを効率よくデプロイできるようにする
旧クラスターから新クラスターにリクエストを手軽に素早く切り替えられるようにする

解決へのアプローチ

ArgoCDのApplicationSetを利用する

ArgoCDはデプロイ設定をApplicationというカスタムリソースで管理しています。Applicationに主に定義している内容は以下の通りです。

Manifestを取得するリポジトリとブランチやリビジョン
デプロイ先のクラスター
Namespace

B/Gアップグレード時にはデプロイ先のクラスターが異なる、2つのApplicationを作成する必要があります。デプロイするアプリケーションが多いほど管理が煩雑になっていきます。

ApplicationSetはApplicationの管理をまとめることができます。これを利用することで複数のクラスター分のApplicationリソースを自動的に作成することができます。

さらにGeneratorというパラメータを利用することで、ArgoCDに登録されているクラスターや指定したクラスターのリスト分だけApplicationを作成することが可能です。

argo-cd.readthedocs.io

ApplicationSetを利用することで新旧クラスター用のデプロイ設定を、効率よく管理できるようになると考えています。

AWS Loadbalancer ControllerのTargetGroupBindingを利用する

AWS Loadbalancer ControllerはKubernetesのアドオンです。 KubernetesのIngressリソースを作成するとALBがプロビジョニングされます。

つまり以下の図のようにクラスター毎にALBが作成されます。

この方法だと基本的にはDNSの切り替えでクラスター移行することになります。これでも問題はないのですが、DNSをキャッシュしているクライアントがあった場合に完全に切り替わるのを待つ必要があります。

AWS Loadbalancer ControllerにはTargetGroupBindingというカスタムリソースがあります。これを利用すると既存のTargetGroupを利用してPodを公開することができます。

つまりIngressを作成しないためALBはIaCなどKubernetesのライフサイクルの外で管理できます。

TargetGroupBindingを利用すると以下の図のように、新旧クラスターで同じALBを利用して、異なるTargetGroupにぶら下がる構成となります。

これによりALBのWeightedRoutingをが利用でき、新クラスターにリクエストを少しずつ移行することが可能となります。

クラスタ別のリソース定義の書き換えをどうするか

ここまで紹介した内容の改善を行って来た結果、一部問題が生じました。 TargetGroupBindingを利用すると、クラスター別で異なるTargetGroupのARNをManifestに記述する必要があります。このARNをどのようにして書き換えるかという問題が生じました。

私達はKustomizeを利用して環境毎(Dev/Stg/Prd)のManifestの管理を行っています。そのため新旧クラスター毎にディレクトリを分けてkustomization.yamlを作成しました。ApplicationSet においては、クラスター別にロードするパスを分けることで対応しました。具体的なファイル構成を以下に記述します。

ディレクトリツリー

├── production
│   ├── kustomization.yaml
│   ├── ...
├── production-blue-cluster
│   ├── kustomization.yaml
│   └── patches
│       └── targetgroupbinding.yaml
└── production-green-cluster
    ├── kustomization.yaml
    └── patches
        └── targetgroupbinding.yaml

上記の./production配下のファイル群はこれまでデプロイに利用していた既存のファイルです。 production-[blue|green]-clusterが新規追加したディレクトリとkustomization.yamlになります。

`production-[blue|green]-cluster/kustomization.yaml`

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
- ../production

patches:
  - patches/targetgroupbinding.yml

既存のkustomizeの構成には手を入れずTargetGroupBindingに関する記述のみpatchをあてるような構成にしています。

patches

---
apiVersion: elbv2.k8s.aws/v1alpha1
kind: TargetGroupBinding
metadata:
  name: my-tgb
spec:
  targetGroupARN: 'arn://hogefugapiyo'
  networking:
    ingress:
      - from:
        - securityGroup:
            groupID: 'sg-hogefugapiyo'

patchには新旧クラスターで異なるTargetGroupのARNとALBのセキュリティグループIDを記述します。

ArgoCD ApplicationSet

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: my-app
  namespace: my-service
spec:
  generators:
  - clusters: {} # Automatically use all clusters defined within Argo CD
  template:
    spec:
      source:
        path: k8s-manifest/project/production-{{cluster}} 
      ...

ArgoCDのApplicationSetではGeneratorを利用して{{cluster}}部分を変数化することで、自動的にB/Gクラスター用のデプロイ設定(Applicationリソース)を作成することができます。

さいごに

EKSクラスターのバージョンアップ作業を効率化するための取り組みについて紹介しました。 TargetGroupBindingを利用したクラスターのB/Gアップグレードはよく耳にしますが実際に私達の環境で実践してみると課題があり様々な解決方法があることを知りました。

今回、私達はこのブログに書いた方針で対応をとりましたが、今後運用を進めるとよりよい方法やツールを知ることになると思うので、このような改善は継続してどこかで公開できればと思います。

明日のはてなエンジニアAdvent Calendarは id:kouki_dan さんです。

2022-05-13

AWS Certified Solutions Architect Professional の更新試験に合格しました

少し前の話しですが、AWS Certified Solutions Architect Professionalが有効期限をむかえるということだったので更新のために受験しました。結果は無事に合格&スコアアップすることができたのでどうやって勉強したかを残しておきます。

自身のスペック

AWS暦
- 6年くらい
- 仕事で本格的に触り始めたのは4年前
資格
- AWS Certified Solutions Architect - Associate
- AWS Certified Developer - Associate
- AWS Certified Solutions Architect - Professional
仕事
- SREです。ここ2年くらいはkubernetesを中心にAWSとGCPを触っている

とりあえず模試を受けた

模試の結果は合格経験があるもののスコアは55%で手応え全くなしという状態でした(55%は運だと思っている...)。ここから落ち込んだのか、なぜかやる気がなくなってしばらく無の時間が続き試験2ヶ月前から本格的に勉強を開始しました。直前に一気に勉強する体力がなさそうだったので1冊の本を時間をかけて勉強することにしました。

読んだ本

AWS認定ソリューションアーキテクト－プロフェッショナル～試験特性から導き出した演習問題と詳細解説～ | 平山毅, 堀内康弘, 福垣内孝造, 岡智也, 新村俊介, 岡崎靖浩, 池田大, 澤田拓也, 津山晃一, 鳥谷部昭寛, 早川愛 | 工学 | Kindleストア | Amazon

たまたまAmazonにオススメされた本ですが演習問題が多く問題毎の解説がよくまとまってそうだったのでこの本で勉強することにしました。前回、はじめて受験したときは問題文が長く時間内に全部の問題を解くことができませんでした。なので多くの問題に触れて問題に慣れることが必要だと思い演習問題中心の本を選びました。

約2ヶ月の間、平日は1H、休日は2Hを上限と決めて毎日やった（エルデンリングが発売されたためこれ以上の時間確保は無理）

Black Belt オンラインセミナーを利用

普段利用しないサービスについては単語もまったくわからない状態だったのでAWS Black Belt オンラインセミナーの資料やYoutubeを利用しました。特にDirectConnect, Organization などですね。

aws.amazon.com

模試(2回目)

受験2週間前に再度、模試を受けた。初回受験時は有料の模試だったのですがいつの間にかAWS Skill Builderで模試が無料で受験できるようになっていました！

dev.classmethod.jp

20問の問題を解くことができて、ログインすれば問題何度も見返すことができます。問題の解説もあるので前の模試勉強の成果もありスコアは80%でなんとかなりそうな感じになってきました。

テストの手応え

全問解くことがきて時間が結構余った
ほとんどの問題を理解して対応することができた。手応えがなかった問題は1問くらい
それなりにスコアアップできた

というわけで無事に合格できてよかったです（結構不安だったので）。 3時間のテスト時間で問題文の長い問題を素早く解き続けるのは知識も必要だけど、ある程度の訓練が必要だなと感じました。試験の勉強を通して忘れていた制約や便利なアーキテクチャを思い出せたのも良かったです。

2022-03-07

Auroraのインプレースアップグレードは手動で再起動するまでデフォルトパラメータグループで動作するため注意

背景

先日、Amazon Aurora MySQL version 1 ( MySQL 5.6 互換 ) のEOLが2023/02/28に予定されました ( 以降、Aurora MySQL v1と記述 )。 2022/09/27 からAurora MySQL v1の作成ができなくなります。 Aurora MySQL v1で動作しているクラスターをAurora MySQL v2 ( MySQL 5.7 互換 ) or Aurora MySQL v3 ( MySQL8.0 互換 )にバージョンアップする必要があります。

docs.aws.amazon.com

アップグレードの方法

アップグレードの方法は主にインプレースアップグレードとBlue/Greenアップグレードの2種類の方法があります。

インプレースアップグレード

docs.aws.amazon.com

利用中のクラスタでアップグレード処理を実施します。インスタンスのシャットダウンが発生しますが手順はシンプルです。エンドポイントはそのまま保持されるため変更の手間もありません。

Blue/Greenアップグレード

aws.amazon.com (英語ドキュメントしか無さそう)

新しくMySQL5.7のクラスタを構築して、MySQL5.6のクラスタからデータをレプリケーションすることで2つのクラスタが同じデータを保持している状態を作ります。最終的にエンドポイントの切り替えによってバージョンアップを実施します。インプレースアップグレードよりもダウンタイムを少なくすることができます。

インプレースアップグレードを実施して分かった問題

インプレースアップグレードはとてもざっくりですが↓の図のような流れでアップグレード処理が走ります。

f:id:masayosu:20220304172637p:plain — インプレースアップグレードの流れ

問題なのは↑の赤いPending Reboot (再起動保留中) の状態で、再起動を待ちながらDBインスタンスは起動しています。このPending Reboot (再起動保留中) の状態ではデフォルトのパラメータグループ( default.aurora-mysql5.7 )でAurora が動作している状態です。そしてカスタムパラメータ設定を適用するには手動で再起動を実施する必要があります。これはドキュメントにも下記のように書いてあります。

アップグレードプロセス中にカスタムパラメータグループを指定した場合は、アップグレード終了後にクラスターを手動で再起動する必要があります。再起動すると、クラスターがカスタムパラメータ設定の使用を開始できます。

つまりアプリケーションを起動した状態でインプレースアップグレードを実施した場合、カスタムパラメータグループの内容によってはサービス影響が発生する可能性があります。

対策

アップグレードの前後でアプリケーションを停止する

インプレースアップグレードの所要時間はデータ量やクラスターのビジー状態によって変わってくるのでアプリケーションの停止時間が読みにくいというところはあります。

Blue/Greenアップグレードを採用する

Blue/Greenアップグレードはクラスタを新しく構築するためエンドポイントを参照している箇所を変更する必要があります。参照している箇所が把握できていなかったり、変更箇所が多かったりすると結構大変な作業になりそうです。

まとめ

2023/02/28 に Aurora MySQL v1 が EOL を迎えます
アップグレードの方法はインプレースアップグレードとBlue/Greenアップグレードの2種類
カスタムパラメータを利用してインプレースアップグレードを行う場合には注意が必要

2021-12-15

はてなにおけるCloudNative推進会の活動について

こんにちは。

はてなでSREをやっているid:masayosu です。

この記事ははてなエンジニアAdvent Calendarの15日目のエントリです。

サブ会と呼ばれている組織の一つ、CloudNative推進会について紹介します。

サブ会について

はてなにはサブ会という集まりがあります。

サブ会というのは所属する組織とは別で、あるテーマに興味を持ったメンバーの集まりです。テーマに関わる知見を深めていくような活動を行い、その内容を社内に共有するような働きをするため会社公認の組織です。

サブ会には以下のようなメリットがあります。

予算要望をあげることができる
自分の興味あるテーマについて業務時間を利用して調査することができる
個人の成果目標の一部にサブ会での活動成果を含めることができる

個人調査やボランティア活動になりがちな活動の成果をフィードバックすることで会社に活動を認めてもらえるといった制度です。

CloudNative 推進会について

はてなの技術グループでは2019年からコンテナ化を推進していて、新旧さまざまなサービスをコンテナで運用するようになりました。CloudNative推進会は2019年に発足され、コンテナ化をサポートするための活動を継続して行っています。

はてな社内で課題となっているテーマを半期に一度選定して、技術グループのサポートとなるような成果物をアウトプットしています。

これまでの活動

活動テーマを選定するために社内のサービスチームのコンテナ化の現状をヒアリングました。そのヒアリングの結果と Cloud Native Trail Mapを見て、はてな技術グループの現在地を確認します。そして解決できたら一番嬉しい題材を半期のテーマとして選定します。

これまでの活動で、社内向けに出した成果物を3つ紹介していきます。

コンテナチェックリスト

コンテナチェックリストとはアプリケーションをコンテナ化する際のノウハウをチェックリスト形式でまとめたものです。

アプリケーション対応、Dockerfile、イメージ管理、CI/CD、オーケストレーション、モニタリング、ログといった項目毎にチェックリストを作成しています。

アーキテクチャの設計段階やリリース前のチェックとして各サービスチームに利用してもらっています。

f:id:masayosu:20211210182919p:plain

CloudNative CI/CD

CI/CDの定義とそのプラクティスをまとめたドキュメントです。

CI/CDのShipプロセスを工程(ステージ)に分割して一般的なワークフローを提示しています。

ツールとしてのCI/CDの理解ではなく抽象度を上げて理解することで各ステージでの役割と責任範囲を明確にすることができました。適切な役割でステージを分割できるとリリースサイクルを早めたりリリースリスクが低減できるメリットがあります。

f:id:masayosu:20211210183808p:plain

CloudNative Batch Processing

社内においてWebアプリケーションのコンテナ化についてはノウハウが蓄積されてきていたのでBatchに目を向けてノウハウををまとめました。CloudNativeな環境でBatchを動作させる場合、Batchアプリケーション以外の管理( Event Source, Monitoring, Storage, LogCollector)はプラットフォームが持つマネージドなサービスを頼ることができます。

ただ、それらのマネージドなサービスを利用する際に意識するポイントがいくつかあります。このあたりの話については先日のHatena Developpers BlogでもCloudNative推進会のメンバーでもある id:tkzwtksさんの記事でも触れられています。

developer.hatenastaff.com

f:id:masayosu:20211210184626p:plain