まっしろけっけ

めもてきなやーつ

EKS で Auto Scale 導入した後のトラブルを解消する

はじめに

shiro-16.hatenablog.com

Auto Scale 導入に関しては上記を参照。

今回のトラブルとは

Auto Scale によって workernode 自体は増えたのにその workernode に pod が作られた時に IP が の状態のままで pod が起動しないというもの。

調査をする

正常に pod が起動する workernode と正常に pod が起動しない workernode を比べると後者は セカンダリプライベート IP の欄に IP がない事がわかった。さらにその workernode のサブネットをみると 利用可能な IPv4 アドレス が 0 になっているというのが確認できた。

数時間後にそのサブネットの 利用可能な IPv4 アドレス をみると数字が増えていることわかった。

つまり workernode の セカンダリプライベート IP に割り当てられた IP が workernode が Auto Scale によって削除された後に再利用可能になるまでに時間がかかり過ぎて IP が足らなくなるという現象ということを突き止めた。

対応する

利用可能な IPv4 アドレス を増やす

上記の現象を AWS の中の人に共有した際に「もともと大量の IP を用意して使うものなので...」(意訳)ということを言われて、ですよね〜となったので単純に workernode に割り当てられるサブネットの IPv4 CIDR を変更して利用可能な IPv4 アドレス を増やすということをやった。

これで上記のトラブルは発生しなくなった。がしかし仮に今後アクセスが増えて workernode の数が大量に必要になった場合などに同じ現象に遭遇しないとも限らないということでもう一つ対応を行ってみた。

ネットワークインターフェイスを定期的に掃除する

workernode(というか EC2) の IP 周りはネットワークインターフェイスを見る事によって現在の status を確認できる。

status が available のものは定期的に削除されている模様というのがわかった。がしかしこの間隔が長すぎるので上記の問題が発生する

という事でこちら側で短い間隔でネットワークインターフェイスを掃除するという対応を行った。

Kubernetes の CronJob でやって貰った。

ネットワークインターフェイスを掃除するスクリプト

まずは AWS SDK for Ruby | AWS を使用してネットワークインターフェイスを掃除するスクリプトを作成

require 'aws-sdk'

ec2 = Aws::EC2::Client.new()
filters = {
  filters: [
    {
      name: :status,
      values: [:available]
    },
    {
      name: :description,
      values: ["aws-K8S-i-*"] # 今回は workernode 用に作成されたものだけ削除する
    }
  ]
}
ec2.describe_network_interfaces(filters).network_interfaces.each do |network|
  ec2.delete_network_interface({network_interface_id: network.network_interface_id})
end

これだけ

CronJob の yaml を用意する


15 分ごとに上記のスクリプトを実行する CronJob を用意する。
aws-sdk の install が遅いので aws-sdk 入りの image を用意しても良いと思います。(自分はそうしている)

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: network-interface-releaser
spec:
  failedJobsHistoryLimit: 1
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - command:
            - gem
            - install
            - aws-sdk
            - &&
            - ruby
            - network-interface-releaser.rb
            env:
            - name: AWS_REGION
              value: ap-northeast-1
            image: ruby:2.7.0
            name: network-interface-releaser
          restartPolicy: Never
  schedule: '*/15 * * * *'
アクセス権限周りの設定

下記のアクセス権限を持つユーザを追加して アクセスキー ID などを kubernetes の Secret にして使う(この場合上記の yaml に env などの追記が必要)か workernode の IAM に追加すると CronJob からネットワークインターフェイスの操作が可能になる。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:DeleteNetworkInterface",
                "ec2:DescribeNetworkInterfaces"
            ],
            "Resource": "*"
        }
    ]
}
最後に CronJob の yaml を apply する

EKS の cluster に yaml を apply すれば定期的に CronJob がネットワークインターフェイスを掃除してくれて綺麗な状態を保ってくれるようになる。

さいごに

個人の見解ですが、調査する時に正常に動作しているものと正常に動作していないものが既に両方存在してると勝ったなって思いますよね。

AWS SAM CLI を使って AWS Lambda をいい感じに管理する

はじめに

github.com
今回使うのは上記

Lambda 環境をローカルで動かしたり出来るので動作確認とかがすごく便利になるやーつ

実際に使う

インストール

今回は mac にインストールする

$ brew tap aws/tap
$ brew install aws-sam-cli
$ sam --version
SAM CLI, version 0.41.0

サンプルのアプリを作ってみる

今回は sam-app という名前のアプリを Golang で作成します。

$ sam init --name sam-app --runtime go1.x
$ cd sam-app
$ tree ./
├── Makefile
├── README.md
├── hello-world
│   ├── main.go
│   └── main_test.go
└── template.yaml

ローカルで動作確認

まずはローカルで動作確認をしてみる

$ GOOS=linux GOARCH=amd64 go build -o hello-world/hello-world ./hello-world # まずは build
$ sam local start-api
Mounting HelloWorldFunction at http://127.0.0.1:3000/hello [GET]
# http://127.0.0.1:3000/hello にアクセスするとレスポンスが返ってくる
# 初回は Image の DL が走るので時間がかかる

デプロイする

$ sam deploy -g # 初回は対話式で色々入力したいので -g をつける
# 色々な IAM 周りの権限を作ってくれる
# samconfig.toml というファイルが作られる
------------------------------------------------------------------------------------------------------------------------------------------------------------------------
OutputKey-Description                                                                                OutputValue
------------------------------------------------------------------------------------------------------------------------------------------------------------------------
HelloWorldFunctionIamRole - Implicit IAM Role created for Hello World function                       arn:aws:iam::0000:role/sam-app-HelloWorldFunctionRole-xxxxx
HelloWorldAPI - API Gateway endpoint URL for Prod environment for First Function                     https://xxxxx.execute-api.ap-northeast-1.amazonaws.com/Prod/hello/
HelloWorldFunction - First Lambda Function ARN                                                       arn:aws:lambda:ap-northeast-1:0000:function:sam-app-HelloWorldFunction-xxxx
------------------------------------------------------------------------------------------------------------------------------------------------------------------------
$ sam deploy # 2 回目以降

コレで deploy が完了するので上記の HelloWorldAPI - API Gateway endpoint URL for Prod environment for First Function に記載されている URL にアクセスするとレスポンスが返ってきます。

/hello/ をやめてみる

endpoint 変更したいなって気持ちなので変更してみる

$ git diff
diff --git a/template.yaml b/template.yaml
--- a/template.yaml
+++ b/template.yaml
@@ -22,7 +22,7 @@ Resources:
         CatchAll:
           Type: Api # More info about API Event Source: https://github.com/awslabs/serverless-application-model/blob/master/versions/2016-10-31.md#api
           Properties:
-            Path: /hello
+            Path: /
             Method: GET
       Environment: # More info about Env Vars: https://github.com/awslabs/serverless-application-model/blob/master/versions/2016-10-31.md#environment-object
         Variables:
@@ -34,7 +34,7 @@ Outputs:
   # https://github.com/awslabs/serverless-application-model/blob/master/docs/internals/generated_resources.rst#api
   HelloWorldAPI:
     Description: "API Gateway endpoint URL for Prod environment for First Function"
-    Value: !Sub "https://${ServerlessRestApi}.execute-api.${AWS::Region}.amazonaws.com/Prod/hello/"
+    Value: !Sub "https://${ServerlessRestApi}.execute-api.${AWS::Region}.amazonaws.com/"
   HelloWorldFunction:
     Description: "First Lambda Function ARN"
     Value: !GetAtt HelloWorldFunction.Arn
$ sam deploy 
------------------------------------------------------------------------------------------------------------------------------------------------------------------------OutputKey-Description                                                                                OutputValue
------------------------------------------------------------------------------------------------------------------------------------------------------------------------HelloWorldFunctionIamRole - Implicit IAM Role created for Hello World function                       arn:aws:iam::0000:role/sam-app-HelloWorldFunctionRole-xxxxx
HelloWorldAPI - API Gateway endpoint URL for Prod environment for First Function                     https://xxxxx.execute-api.ap-northeast-1.amazonaws.com/Prod/hello/
HelloWorldFunction - First Lambda Function ARN                                                       arn:aws:lambda:ap-northeast-1:0000:function:sam-app-HelloWorldFunction-xxxx
------------------------------------------------------------------------------------------------------------------------------------------------------------------------
$ curl https://xxxx.execute-api.ap-northeast-1.amazonaws.com/Prod
Hello, 0.0.0.0

Golang の場合はどのアプリが使われるのか?

Golang の場合は build されたアプリが使われるのか勝手に build されるのか?という部分が少し謎だったので調べてみた。

$ git diff hello-world/
diff --git a/hello-world/main.go b/hello-world/main.go
--- a/hello-world/main.go
+++ b/hello-world/main.go
@@ -41,7 +41,7 @@ func handler(request events.APIGatewayProxyRequest) (events.APIGatewayProxyRespo
        }

        return events.APIGatewayProxyResponse{
-               Body:       fmt.Sprintf("Hello, %v", string(ip)),
+               Body:       fmt.Sprintf("Hello, %v", string("test")),
                StatusCode: 200,
        }, nil
 }
$ sam deploy 
$ curl https://xxxx.execute-api.ap-northeast-1.amazonaws.com/Prod
Hello, 0.0.0.0 # 変わってない
$ GOOS=linux GOARCH=amd64 go build -o hello-world/hello-world ./hello-world
$ sam deploy 
$ curl https://xxxx.execute-api.ap-northeast-1.amazonaws.com/Prod
Hello, test # 変わった

ということはどこかで build 後のバイナリを指定してるんだろうなと思って template.yaml を覗いてみたら Handler: hello-world と記述された部分があったのでもう少し実験

$ mv hello-world/hello-world hello-world/hoge
$ git diff template.yaml
diff --git a/template.yaml b/template.yaml
--- a/template.yaml
+++ b/template.yaml
@@ -15,14 +15,14 @@ Resources:
     Type: AWS::Serverless::Function # More info about Function Resource: https://github.com/awslabs/serverless-application-model/blob/master/versions/2016-10-31.md#awsserverlessfunction
     Properties:
       CodeUri: hello-world/
-      Handler: hello-world
+      Handler: hoge
       Runtime: go1.x
$ sam deploy
$ curl https://xxxx.execute-api.ap-northeast-1.amazonaws.com/Prod
Hello, test # 動いてる

ということでバイナリの名前を変えて template.yaml 内で指定していた場所を書き換えたら、元どおりに動いているので推測通り Handler 部分で指定されているというのが確認できた。

最後に

まだ AWS SAM CLI について調べきれていないので触りながら動作を確認してみた。

最終的にやりたいことは example.com > CDN > Lambda といった感じで CDN を挟んでアクセスを Lambda に向けたいというものなのだけれど、CDN が CloudFront ならサクッと出来るが今回は諸々の事情から Akamai を使うので Akamai の設定でハマって進捗が悪くここまで...

続きは第二回のブログがあるかもしれない

BigQuery に入門したのでハマったことをメモする

はじめに

最近社で BigQuery にクエリ投げて結果を取得して、その結果をごにょごにょするというのをやり始めて BigQuery に入門したのだけれどそりゃそうですよねということでハマったのでメモとして残しておく。

基本的な処理

使うのは Rubygoogle-cloud-bigquery です。
README にも載ってますが基本的には下記のような感じで書きます。

$ gem install google-cloud-bigquery
$ irb
require "google/cloud/bigquery"

bigquery = Google::Cloud::Bigquery.new(
        project_id: "hogehoge",
        credentials: gcp_credential_path
      )

data = dataset.query "SELECT * FROM table"

data.each do |row|
  puts row[:hoge]
end

table が既に存在していればこんな感じで情報が取得できるわけですよ。

取得する件数が多い場合

今回ハマったのがこのパターンです。クエリで取得する件数が多い(100000件以上の)場合実は上記の方法では 100000 件しか取得できないのであった...
Treasure Data の workflow の結果取得する際は気にしなくてよかったのでハマったが limit かかるのは当然と言えば当然ですね...

data = dataset.query "SELECT * FROM table LIMIT 1000000"

data.count
=> 100000

table に 100000 件以上のデータがあった場合上記のような結果になってしまいます。
なのでお手軽に全件取りたい場合は下記のようにする必要があります

data = dataset.query "SELECT * FROM table LIMIT 1000000"

begin
 puts data.count
end until (data = data.next).nil?

Google:: Cloud:: Bigquery::Job を使う場合は下記のような感じ

dataset = bigquery.dataset("dataset_name")
job = dataset.query_job "SELECT * FROM table LIMIT 1000000"
job.wait_until_done!

data = job.data
begin
 puts data.count
end until (data = data.next).nil?

さいごに

BigQuery なんか色々便利そうなのでちゃんと情報収集しなければ...となっている

Github Projects を使ってドラッカー風エクササイズをやった

はじめに

ドラッカー風エクササイズとは

ドラッカー風エクササイズとはというのは社のけんちゃんくんさんが書いてある下記の記事を参照してください

tech.pepabo.com

やるとなった経緯

僕が社に入社した直後のチームでドラッカー風エクササイズが開催され、入社したばかりの自分が周りに何を期待されているのか?や自分の強みはこれですというのを発表できる場があったのはとても良い機会だったという記憶があり、CTL を勤めている minne 事業部では今年から少しチーム体制の変更があったのでこれを機にやるかとなったのでした。

Github Projects を使った経緯

過去の経験からいくつか本質ではないところに気をつける必要があったという記憶がありそこを何とかしたいという思いがありました。

それが下記のようなものです。

  • (自身が)字が汚いので付箋に文字を丁寧に書くということに意識と時間を取られる
  • 記入後は付箋を見て物事が進んでいくのだが、付箋では小さくみんなで見づらい
  • 終わった後に振り返るには写真を撮るや付箋を保存するなどがあり振り返りづらい

これらがあったのですが、これまたけんちゃんくんさんに社のデザイナーが notion を使ってやってたというのを教えてもらいました。

それがこちら

speakerdeck.com

この資料を読んでたら notion でやることで先に挙げた懸念が解消されるし良いなとなったのですが、 notion のアカウントそもそも全員持ってないかもな?というのがあり閃いたのが Github Projects を使うという方法です。

Github Projects を選んだ理由は下記のようなものです。

  • 社では GitHub Enterprise を採用しており、全社員アカウントを持っている
  • 社の情報のほとんどが GitHub Enterprise 上に集まっている
  • 先で挙げた懸念も全て解消される

やり方

ここからは実際のやり方の説明です。

1. Project 作成

f:id:shiro-16:20200124142329p:plain

こんな感じで入力して作成

2. 参加者に自身の名前で column を作成してもらう

f:id:shiro-16:20200124142403p:plain

3. 自身に関しての質問を記述する

f:id:shiro-16:20200124142521p:plain

4. 検索窓に author:自身のアカウント でフィルターをかける

f:id:shiro-16:20200124142633p:plain

これによって誰のカラムに記入したか把握しやすくなる

5. 他人に関しての質問を記述する

f:id:shiro-16:20200124142733p:plain

これ以降は基本的には最初にあげた社のテックブログの内容と同じに進んでいきます。
今回は終わった後の感想も各位の column に書いてもらいました。

さいごに

Github Projects を使用することでより本質に意識を割くことが可能になったと感じます。

また、いつでも普段使っているリポジトリを見直せば振り返ることが可能になっているというのも便利ポイントかと思いました。

Kubernetes Meetup Tokyo #24 で登壇してきた #k8sjp

Kubernetes Meetup Tokyo とは

k8sjp.connpass.com

Kubernetesのことを詳しく聞く会とのこと

登壇経緯は青山さん(以下青)

青「次回○○って回なんですけどネタないですか?」
僕「〜って感じなら喋れますよ」
青「ではそれで」

雑にまとめるとこんな感じ

登壇内容

speakerdeck.com


minne の開発環境が kubernetes 導入したらこんな感じに変わりましたよって感じで、
導入以前に感じていた課題は解決したけど新しい課題が出てきたよという内容

twitter 眺めてると紹介したツール知らんかったというのもちらほら見かけたので、よかったかなと(普通にみんな知ってるんでは?意味あるのか?と不安になってた)

質問もいくつかもらったのと懇親会でも色々お話できたのでよかった.

資料内で紹介している telepresence に関しては下記の記事を参照してください
shiro-16.hatenablog.com

その他の内容

体調が無だったのでほぼ記憶がアレなのですが、カーネルの話があったりエフェメラルコンテナの話があったり(資料はインターネットを探してください...)

Rails Developers Beer Bash 〜Railsのトレンドとこれから〜 で登壇してきた #railsbeerbash

Rails Developers Beer BashRailsのトレンドとこれから〜 とは

techplay.jp

Rails6 についてどうのこうの喋る会(雑)

登壇経緯などは資料に書いてあるので読んでください

登壇内容

Beer Bash ということもあり、登壇者の人々で乾杯前に練習と称して先に飲んでいたのでちょい酔いという状態で登壇した。

speakerdeck.com

Rails6 にする為に TA をしたって話

結局リリース自体は出来なかったので TA は失敗だったのだけれど、あとはリリースのみなのでまぁほぼ成功では?

その他の内容

www.slideshare.net

Rails6 で対応された multi db の話

minne でも switch_point を使用して multi db 対応してるので Rails 標準で対応されるのは嬉しいですね。
Rails6 upgrade 後に switch_point から標準に移行すると思うのでその時に参考になりそうな資料でした。

パネルディスカッション

登壇だけという話だったのですが、急遽前日にパネルディスカッションも出てくれんか?と言われて出ることになった。
事前に頂いていた質問のほとんどが既に出来上がっている資料に書いてあり...これ登壇時にほぼ話すんじゃが...みたいな気持ちになって不安だったが、流石モデレーターのうなすけという感じでなんかいい感じになった気がする

minne のマイクロサービス化の話(たぶん過去にこのブログでも触れた)とか並列 test が標準機能になって嬉しいとか gem の update 戦略とか話した記憶(途中からすごくトイレ行きたくなったのだけは鮮明に覚えている)

自分以外のパネラーの人々の所属する社での方針やお悩みなども聞けてよかった。

懇親会 & LT大会

LT の資料は割愛(探すのがめんどくさかったとかそういうんじゃないんだ...)
それな〜とあるあるな感じの内容が多かったような。

懇親会もなんかずっと喋っていた気はする。

  • 手動テストする際の範囲の話
  • dependabot と GHE の話
  • 管理画面の gem の更新の話

とか他にも色々話した記憶

最後に

最近クラウドネイティブ関連の事ばかりやっていて Ruby/Rails 関連の勉強会も凄く久しぶりだった気がするんですが、こっちの方が知ってる人が多いので安心するというのはあるなという気持ちになって不思議な感じ

他社の人々と Rails 関連の話をがっつり出来たのも久しぶりだったのでとても有意義な時間を過ごせました。
ありがとうございました。

EKS で Auto Scale 導入したお話

はじめに

お仕事で開発している minne というサービスは OpenStack と AWS のハイブリットクラウドなのだけれど(詳細はこちら)色々つらみがあってそのつらみを解決するために Kubernetes への移行を行ったんですよ。(移行についてはまた別のお話なので何処かで)

ハイブリットなのは変わらず OpenStack に cluster 構築してというのと AWS 側は EKS を使うという構成。

それで EKS 側は Auto Scale 使えるじゃん!ということを思い出したので実際に導入したという話。

Auto Scale 導入までの道のり

Auto Scale を導入するまでに必要な手順がいくつかあるので順を追って解説

Metrics Server の導入

docs.aws.amazon.com

だいたい手順は上記に書いてあるんですけど このリポジトリ clone して version とかきになるなら選んで apply すれば良いという感じ

$ git clone git@github.com:kubernetes-incubator/metrics-server.git
$ cd metrics-server

# このままだと最新の master なので最新のリリース version に切り替えるとかやる

$ kubectl apply -f deploy/1.8+/ # Kubernetes の version によって 1.8+ じゃなくて 1.7 とかのディレクトリを選ぶ必要がありそう

$ kubectl get deployment metrics-server -n kube-system --watch
NAME             DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
metrics-server   1         1         1            1           10d

$ kubectl top node
NAME                                              CPU(cores)   CPU%      MEMORY(bytes)   MEMORY%
ip-xxx-xxx-xxx-xxx.ap-northeast-1.compute.internal   xxxxm        15%       xxxxMi          60%
ip-xxx-xxx-xxx-xxx.ap-northeast-1.compute.internal   xxxm         3%        xxxxMi          54%
ip-xxx-xxx-xxx-xxx.ap-northeast-1.compute.internal   xxxxm        24%       xxxxMi         65%

これで node や pod の metrics を確認できるようになるので Horizontal Pod Autoscaler を使うことができるようになる。

Horizontal Pod Autoscaler

Horizontal Pod Autoscaler - Kubernetes

Horizontal Pod Autoscaler(以下 HPA) は雑にいうと負荷によって pod 数を増減(スケールイン/アウト)させるやーつ

下記のような yaml を用意する。

# hpa.yaml
apiVersion: autoscaling/v2beta1
kind: HorizontalPodAutoscaler
metadata:
  name: sample-hpa
spec:
  minReplicas: 2 # 最小の pod 数
  maxReplicas: 200 # 最大の pod 数
  metrics:
  - resource:
      name: cpu # pod の cpu の使用率を基準に増減させる
      targetAverageUtilization: 20 # 使用率 20% を基準に増減させる
    type: Resource
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: sample-deployment # 増減させたい deployment の名前を指定
$ kubectl apply -f hpa.yaml
$ k describe hpa
Name:                                                  sample-hpa
Namespace:                                             default
Labels:                                                <none>
Annotations:                                           kubectl.kubernetes.io/last-applied-configuration=.....
CreationTimestamp:                                     Fri, 19 Jul 2019 12:03:05 +0900
Reference:                                             Deployment/sample-deployment
Metrics:                                               ( current / target )
  resource cpu on pods  (as a percentage of request):  15% (xxxxm) / 20%
Min replicas:                                          2
Max replicas:                                          200
Conditions:
  Type            Status  Reason              Message
  ----            ------  ------              -------
  AbleToScale     False   BackoffBoth         the time since the previous scale is still within both the downscale and upscale forbidden windows
  ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request)
  ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
Events:
  Type    Reason             Age   From                       Message
  ----    ------             ----  ----                       -------
  Normal  SuccessfulRescale  33s   horizontal-pod-autoscaler  New size: 4; reason: cpu resource utilization (percentage of request) above target

これで HPA が有効になった。

最初は Metrics の current 部分が unknown となるが待っていれば Metrics 収集して正常になるはず。

注意が必要なのは対象の deployment の全 container の resources (今回は cpu が対象なので cpu)が設定されていないと unknown のままで Events にエラーが出てるはず。他にも対象の deployment と同じ label 名の deployment の各 container も同様に resources が設定されてないといけない > see

HPA が有効になったので pod が増減するか見てみる

# アクセス数とかは調整してください
$ ab -n 100000 -c 100 "対象の deployment へアクセスが流れる IP を指定"

# 別プロセスで
$ kubectl get pods --watch

これで pod が増えたり減ったりする様子が眺められるはず。
k describe hpa で hpa の様子を見ると Events に pod を増減させている情報も表示されます。



これで HPA の導入は終わり

Cluster Autoscaler

GitHub - kubernetes/autoscaler: Autoscaling components for Kubernetes

最後に workernode を増減していきます。

まずは workernode の IAM に Auto Scale 周りのアクセス権を付与する

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "autoscaling:DescribeAutoScalingGroups",
                "autoscaling:DescribeAutoScalingInstances",
                "autoscaling:DescribeLaunchConfigurations",
                "autoscaling:SetDesiredCapacity",
                "autoscaling:TerminateInstanceInAutoScalingGroup"
            ],
            "Resource": "*"
        }
    ]
}

上記のポリシーを作成し workernode のロールにアタッチする。

Autoscaler のマニフェストこちら

YOUR CLUSTER NAME の箇所を自身の環境に合わせて apply

pod の増減で確認した時のように負荷をかけつつ下記で log を眺める

$ kubectl logs -f deployment/cluster-autoscaler -n kube-system

# 別プロセスで
$ k get node --watch

これで EKS での Auto Scale の導入はおしまい

さいごに

HPA を有効にするところで少しハマりましたが、シュッと Auto Scale が有効にでき AWS の使用料も抑えることができたので便利でした。

本番導入して 10 日程ですが今の所問題は起きてません。