負荷試験ツールの選定時に考慮することまとめ

概要

負荷試験ツールの選定を行うときに考慮することをまとめる

機能

  • ログインが必要なページへの対応
     Cookie変更など
  • 負荷分散機能
     負荷試験クライアントマシンのリソース上限に達する場合は負荷分散を考慮する必要あり
  • 複数ユーザ対応
     ファイル読み込み等で複数のユーザ情報を再現する
  • CI化
  • 複数シナリオ対応
  • 複数シナリオの個別グラフ化
  • 公式のDockerイメージ

作業コスト

  • 実行手順の少なさ
  • 可視化作業の手順の少なさ
  • 初期環境構築手順の少なさ
  • 負荷試験実行結果収集コスト
  • グラフ作成コスト

可視化性

  • データ項目数
  • グラフ作成機能

金銭コスト

  • 有料か無料
  • SaaS版はあるか

保守コスト

  • 使用言語 プロダクトに親和性のある言語か
  • 日本語事例、ドキュメント
  • ドキュメント項目
  • GitHubスター数、コミッタ数

複業の契約が半年間継続したのでやっていることをまとめる

概要

複業(副業)の契約が半年間継続しているので感想やTipsをまとめる。

案件獲得

スカウトサイトで単価と得意領域を提示。
スカウトが入るので話をすり合わせて契約する。
エージェントはなし。

勤務形態

契約方法の違いを確認し、準委任契約で契約。
契約時は契約書をよく読むこと。(契約書を読んで請負から準委任に変えていただいた。)

勤務時間、勤務ペース

昨今の自粛により時間が浮いてしまったため、その分を副業に当てている。
副業開始当初は土日に稼働していたが、疲れの蓄積や曜日感覚が狂うので週1は必ずフリーの日を設けるようにしている。
本業で重たい仕事が終わった後に副業すると頭が働かないので、平日は朝に稼働する。

担当範囲

チーム構成は6人程度のチーム
担当範囲は設計、クラウドインフラ構築、CI/CD構築、モニタリング構築、バックエンド実装、フロントエンド実装、技術調査など
使っている技術はReact,TypeScript,Go,Terraform,AWSなど

Tips

タスクの認識合わせ

日中は本業をしているので、非同期主体のコミュニケーションになる。 細かく認識合わせを行い、認識齟齬の防止、期待値のすり合わせをおこなう。
タスクを進める前に

  • なぜやるか?
  • 完了定義
  • 成果物

を書いて認識齟齬がないようにする。

わからないところ、認識を合わせたい所があれば、チケット上やPRなどオープンな場所でコミュニケーションする。

期待値の共有

  • どういう経験を積んできたか
  • どのような価値を提供できるか
  • どういう仕事にモチベーションがあるか
    を共有する。

稼働時間のズレ

副業参加なので他メンバーとの稼働時間の量、稼働のタイミングでズレがでてくる。
そのため、同期的な作業が必要なタスクよりは単独で進められるタスクのほうがやりやすく感じた。
わからない所があればオープンな場所で非同期コミュニケーションを取る。
話が込み入りそうなときは必要に応じて口頭のコミュニケーションを選択。

業務の改善提案

ここはやりやすかった、ここはやりにくかったのでこうしたい、などを提案しながら進める。

ドキュメント整備

少数のチームなので担当した範囲で今後も参照される箇所はドキュメント化する。

未経験の技術について

未経験の業務を担当する場合は負荷が増えることを事前に意識し、生活を調整する。
キャッチアップ方法は下記の流れでやることが多い。 https://mzqvis6akmakplpmcjx3.hatenablog.com/entry/2021/01/19/180025

健康

散歩、入浴、ストレッチ、筋トレはやっておく。
整体を開拓中。

その他感想

副業の目的を明確にする

何のために副業をやるのか、スキルアップなのか収入を増やしたいのか優先順位を明確にする。

開発規模の違い

本業が大規模開発なので開発規模の違いが勉強になった。
求められる性能、可用性、開発フローなどが異なるため、要件にあったものを提案する。

依存先が分散する

金銭面、評価面で依存先が分散するので、固執することなく俯瞰して仕事できる。

サイクルを回す

本業で学んだことを複業で活かし、複業で学んだことを本業で活かすことで仕事の理解が深まる。

まとめ

契約書をよく読み、自分の望む形態で契約する。
こまめに適切な手段でコミュニケーションする。
成果の認識を合わせ、成果を出す。  

AWS ECS構築時のメモ

概要

AWS ECSのデプロイフローを構築したときのメモを書き起こす。

terraform version0.13.2

CI/CD

GitHub Actions

aws-actions/amazon-ecs-render-task-definition@v1
及び
aws-actions/amazon-ecs-deploy-task-definition@v1
を利用する。

dev環境

ビルド後にaws-actions/amazon-ecs-render-task-definitionを利用し、aws-actions/amazon-ecs-deploy-task-definitionでデプロイする。

stg及びprd環境

デプロイしたいイメージを更新し、aws-actions/amazon-ecs-deploy-task-definitionでデプロイする。

ecs run-taskでjobを実行する

前提:特定のサービスに対してjobを実行する。 fargateタイプに対してecs run-taskする場合、セキュリティグループ及びサブネットを指定する必要がある。

$SUBNETS=$(aws ecs describe-services --services SERVICE --cluster CLUSTER --query "services[*].networkConfiguration.awsvpcConfiguration.join(',',subnets[])" --output text | sed 's/[^,]\+/"&"/g')
$SG=$(aws ecs describe-services --services SERVICE --cluster CLUSTER --query "services[*].networkConfiguration.awsvpcConfiguration.securityGroups" --output text | sed 's/[^,]\+/"&"/g')
$aws ecs run-task --cluster CLUSTER --launch-type "FARGATE" --overrides "containerOverrides=[{name="server",command=[\"bash\",\"-c\",\"set -a; ls;\"]}]" --network-configuration "awsvpcConfiguration={subnets=[$SUBNETS],securityGroups=[$SG]}" --task-definition TASK_DEF

Terraformのタスク定義について

Terraformでリソース管理する場合、デプロイごとにタスク定義が更新されるので、ignore_changesする必要がある。

resource "aws_ecs_service" "test" {
 ....

  lifecycle {
    ignore_changes = [task_definition]
  }
}

DevOpsチェックリスト技術編

概要

以前書いたメモを公開する。
DevOpsは技術面と文化面があるので、技術編としている。

バージョン管理・ブランチ戦略

  • Gitでバージョン管理している
  • ブランチ戦略を決定している 基本はGitHub flowもしくはgit flowに合わせる。

CI

  • 自動的にビルドできる
  • 自動的にリントできる
  • 自動的にスペルチェックできる
  • 自動的に単体テスト(テストサイズsmall)できる
  • 自動的に統合テスト(テストサイズmedium)できる
  • 自動的にシステムテスト(テストサイズlarge)できる
  • 自動的に脆弱性検査できる
  • 自動的に負荷試験できる
  • 上記項目の結果を通知できる

CD

  • 自動的にデプロイできる
  • リリースに不具合があった場合、1分以内にロールバックできる
  • デプロイ頻度・成功率を計測している

モニタリング

  • リリースに不具合があったときに、検知できる
  • APMを導入している
  • 上記をダッシュボード化している
  • 上記でエラーが発生したとき通知できる
  • フロントエンドパフォーマンスをモニタリングしている
  • 上記の低下を検知できる
  • アプリケーションログのダッシュボードがある
  • 上記でエラーが発生したとき通知できる
  • フロントエンドログのダッシュボードがある
  • 上記でエラーが発生したとき通知できる

IaC

  • インフラリソースをコード化している
  • インフラリソースに手動で変更を加えない運用になっている
  • システム内のリソースをコード化している
  • システム内のリソースに手動で変更を加えない運用になっている

参考

https://aws.amazon.com/jp/devops/what-is-devops/

https://cloud.google.com/devops

https://azure.microsoft.com/ja-jp/overview/what-is-devops/

https://testing.googleblog.com/2010/12/test-sizes.html

Amazon CloudWatch SyntheticsとAWS Chatbotで外形監視をSlackに通知する

概要

Amazon CloudWatch Synthetics + AWS Chatbotで外形監視の通知システムを作ったのでログに残す。

構成図

f:id:mMQnaZ7vL2DWkoU:20210427192432p:plain

作業内容

今回の通知は本番環境のみ利用するのでコード化せず、GUIで作成した。
作業詳細は公式ドキュメント参照。

https://docs.aws.amazon.com/chatbot/index.html
https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html

大まかな手順は下記。

  1. 通知用のSNSトピック作成
  2. AWS ChatBotの作成とSNS連携
  3. Canary作成とSNS連携

Canaryはユースケースに応じたBluePrintが用意されている。今回はHeartBeatを選択。
f:id:mMQnaZ7vL2DWkoU:20210427194051p:plain

Canaryリソースの削除

Canaryを作ると下記リソースが自動で作られる。

  • CloudWatch Alarm
  • lambda(puppeteer実行)
  • S3(結果の保存)

今回の目的の場合、通知用のSNSトピックは自分で作る必要がある。 また、保存先のS3を自動作成されたもの以外にするときは、命名変更の都合上IAMリソースも手動で作成する必要がある。

関連リソースは自動で削除されないので探して手動で削除する。 下記ドキュメントには書いていないがIAM Policyも作られる。 https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/synthetics_canaries_deletion.htm

まとめ

AWS Chatbotを使うことで少ない手順でSlack連携できた。
Amazon CloudWatch Syntheticsを使うことで外形監視システムを導入できた。

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