JavaScriptで数値の有効範囲でバリデーションする

概要

JavaScriptの有効値による丸め方法

Math.max(x,<有効数字の下限>)
Math.min(x,<有効数字の上限>)

例:10進数のRGB値を16進数に変換するとき0~255を有効値とする。 有効範囲を超える値は最も近い値に丸める場合、下記のようになる。

Math.min(Math.max(10, 0), 255).toString(16).padStart(2, "0").toUpperCase()
//"0A"
Math.min(Math.max(1000, 0), 255).toString(16).padStart(2, "0").toUpperCase()
//"FF"
Math.min(Math.max(-1000, 0), 255).toString(16).padStart(2, "0").toUpperCase()
//"00"

K8s負荷試験作業記録

概要

負荷試験を実施したので記録する

環境

AWS(EKS)、Datadog、Gatling

事前準備

  • 負荷試験ツール選定
  • 目標値設定
  • シナリオ作成
  • スケジュール設定
  • 環境構築、試験用踏み台準備
  • モック準備(必要な場合)
  • 関連部署に連絡(必要な場合)

負荷試験実施

  1. 負荷をかける
  2. APM,ログを確認する
  3. 問題のある箇所の特定
  4. 修正

上記ステップを繰り返す。

確認事項

メトリクス

  • K8s
    ClusterのCPU、メモリ使用率
    NodeのCPU、メモリ使用率、DiskUsage
    Deployment単位のCPU、メモリ使用率 ReplicaSet数
    など
  • 各アプリケーション(Datadogでいうservice単位)
    レイテンシ、リクエスト数、エラー数
  • CoreDNS
    リクエスト数、エラーレート、レスポンスタイム
  • アプリケーションログ
    エラーログ、トレース
  • その他インフラリソース
    NatGateway、CloudFrontなど

考慮点

スケールアップかスケールアウトか

アプリケーション特性やモニタリングの容易性が変わる
スケールアップするよりもスケールアウトしたほうが性能が出る場合
細かなスケールアウト、スケールインを繰り返すとモニタリングがしづらい  

PodとNodeのスケールアウト速度の差

Podは立ち上がるのが早いが、Nodeは遅い
しきい値を上げすぎるとNodeのスケールアウトが間に合わないケースがある

スケール特定

線形スケールするか?

アプリケーション特性

  • スパイクアクセスが多いか?
    スパイクアクセスが多い場合はスケールアウトが間に合わない可能性があるので、基本スペックを上げたり、しきい値を低くするなどの対策が必要
  • 時間帯によってリクエスト数は増えるか?
    時間帯が決まっているならスケジュールで事前にスケールアウトしておく
  • 高可用性が求められるか?

改善点

作業人員不足

コンテナ数が多く確認項目も多かったため人員不足を感じた。人員を増やすか、ダッシュボードを有効活用する。
下記のような役割が必要。

  • 負荷試験実施要員
  • 試験記録要員
  • アプリケーションナレッジ要員

参考

https://gist.github.com/voluntas/00da5ea7a1a14d82adf2e718c7d8a145

負荷試験ツールはGatlingを使ったが、k6のドキュメントも概念を知るには良かった。 https://k6.io/docs/misc/glossary

CloudWatch Syntheticsでロールが作れないとき

概要

AWS CloudWatch SyntheticsのcanaryをGUIで作成するとき、 「Create a new role」がグレーアウトして押下できない。 f:id:mMQnaZ7vL2DWkoU:20210304010752p:plain

原因

S3のパスを変更していたから。
IAM Roleを自動作成するとき、ポリシーの設定がデフォルトのS3パスになっている。
そのため、S3のパスを変更するときは、自分でIAM Policyを作成し、それをアタッチしたIAM Roleを作らなければならない。

下記のようなポリシーが作られる。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:PutObject"
            ],
            "Resource": [
                "arn:aws:s3:::cw-syn-results-<ACCOUNT_ID>-<REGION>/canary/<REGION>/<CANARY_NAME>-<HASH>/*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetBucketLocation"
            ],
            "Resource": [
                "arn:aws:s3:::cw-syn-results-<HASH>-<REGION>"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "logs:CreateLogStream",
                "logs:PutLogEvents",
                "logs:CreateLogGroup"
            ],
            "Resource": [
                "arn:aws:logs:<REGION>:<ACCOUNT_ID>:log-group:/aws/lambda/cwsyn-<CANARY_NAME>-*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:ListAllMyBuckets",
                "xray:PutTraceSegments"
            ],
            "Resource": [
                "*"
            ]
        },
        {
            "Effect": "Allow",
            "Resource": "*",
            "Action": "cloudwatch:PutMetricData",
            "Condition": {
                "StringEquals": {
                    "cloudwatch:namespace": "CloudWatchSynthetics"
                }
            }
        }
    ]
}

まとめ

今回、Syntheticsを利用するに当たり、本番環境のみ利用し、一度作成した後に変更が殆どないことから、GUIで作った。
関連して作られるリソースの削除などが面倒だったので、IaCしても良いかも知れない。
Terraformで作っても消してくれないので、自分で作る必要がある。 https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/synthetics_canary

削除するときの手順は下記(これに加えIAM Policyも削除する必要がある。)
https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/synthetics_canaries_deletion.html

package.jsonのバージョンを固定する

環境

$node -v
v14.15.0
$npm -v
6.14.10

結論

$npm config set save-exact true

https://docs.npmjs.com/cli/v7/using-npm/config#save-exact
設定は.npmrcに書き込まれる。

renovateを利用するときにバージョンを固定する必要があるので、この設定が有用。

docs.renovatebot.com

GitHub Actionsで特定のディレクトリ配下が変更されたときだけワークフローを発火する

概要

GitHub Actionsで特定のディレクトリ配下のファイルが変更されたときにワークフローを発火する方法。

結論

トリガーにpathsを使用する。
下記のように書くとhogeディレクトリ配下のファイルが変更されたときのみワークフローが発火する。

on:
  push:
    paths:
    - 'hoge/**'

https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#onpushpull_requestpaths

ユースケース

  • モノレポで各ディレクトリの変更に対して個別にワークフローを発火する
  • 特定の拡張子が変更された場合のみ発火する
  • ドキュメントの更新でワークフローを走らせたくない

など

まとめ

最近モノレポプロジェクトを触っているのでまとめた。

direnvを使ってTerraformにAWSクレデンシャルを設定する

バージョン

$direnv --version
2.21.2
$tf --version
Terraform v0.13.2

方法

Terraformのホームディレクトリに下記の.envrcを追加する。

AWS_PROFILE="<PROFILE_NAME>"
AWS_DEFAULT_REGION="ap-northeast-1"

.gitignoreに.envrcを追加する。

.envrc

これで対象のディレクトリに移動すると、設定されたプロファイルでTerraformを実行できる。

未知のライブラリ、フレームワーク、サービスを使うときのキャッチアップ方法

概要

タイトルの通り

キャッチアップ方法

1. コンセプト、モチベーションを知る

トップページや上の階層に書いてあるので読む。

検索方法

why~,what is~,overview,feature,motivation,conceptなど

2.用語をざっくり知る

用語集として端的に説明されているので初学時の理解に役立つ
ツールを使い始めてから何度か参照するので用語がまとめてある場所を押さえる

検索方法

glossary,FAQなど

3.動かす

実際に動かして理解を深める

検索方法

getting started,tutorialなど

4.ベストプラクティスを調べる

ベストプラクティスやアンチパターンがないか確認する

検索方法

best practice,anti patternなど

わからない事があったとき

前提

英語で調べる

検索順番

  1. 公式ドキュメント
  2. 公式のGitHubリポジトリのISSUES,PR
  3. 公式のコミュニティ、チャット
  4. 公式のGitHubリポジトリのコード検索
  5. GitHubでツール名を調べてどのように使われているか調べる

AWS ECSの例

1. コンセプト、モチベーションを知る

2.用語をざっくり知る

https://docs.aws.amazon.com/general/latest/gr/glos-chap.html

3.動かす

https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-tutorials.html

4.ベストプラクティスを調べる

下記は検索結果の一部
https://aws.amazon.com/blogs/containers/amazon-ecs-availability-best-practices/

まとめ

いつもやっていることをまとめてみた
基本的には公式ドキュメント、リポジトリに書いてある一次情報を参考にする