Takashi Iwamoto

◯沼袋.nighthttps://shirayanagiryuji.connpass.com/event/325230/2024-11-09

AWS⼊社という選択肢、⾒えていますか

If you want to change the network settings for an Amazon ECS service using blue/green deployment with AWS CodeDeploy, you need to edit the AppSpec file and trigger a new deployment.Without knowing this method, you'd either have to recreate the entire ECS service or give up on changing the network settings.For ECS services using blue/green deployment with AWS CodeDeploy, you cannot directly change the network settings.When you try to make changes by calling the ECS UpdateService API, you will encounter the following error:InvalidParameterException: Unable to update network parameters on services with a CODE_DEPLOY deployment controller. Use AWS CodeDeploy to trigger a new deployment.This error message indicates that you need to trigger a new deployment with CodeDeploy, as noted in the documentation.For services using the blue/green (CODE_DEPLOY) deployment controller, only the desired count, deployment configuration, health check grace period, task placement constraints and strategies, enable ECS managed tags option, and propagate tags can be updated using this API. If the network configuration, platform version, task definition, or load balancer need to be updated, create a new AWS CodeDeploy deployment. For more information, see CreateDeployment in the AWS CodeDeploy API Reference.UpdateService - Amazon Elastic Container ServiceNow that we know we need to trigger a new deployment, the question remains: how exactly should we do that?The answer is to "edit the AppSpec file and then trigger a new deployment." If you trigger it without editing the AppSpec file, the network settings won't change.In the case of appspec.yml, edit it as shown below.        NetworkConfiguration:          AwsvpcConfiguration:            Subnets: ["subnet-1234abcd","subnet-5678abcd"]            SecurityGroups: ["sg-12345678"]            AssignPublicIp: "ENABLED"AppSpec File example - AWS CodeDeploySpecify the subnets, security groups, and whether or not to assign a public IP address for the ECS tasks in the AppSpec file.When doing so, you need to specify all three: Subnets, SecurityGroups, and AssignPublicIp.All or none of the settings under NetworkConfiguration must be specified. For example, if you want to specify Subnets, you must also specify SecurityGroups and AssignPublicIp. If none is specified, CodeDeploy uses the current network Amazon ECS settings.AppSpec 'resources' section (Amazon ECS and AWS Lambda deployments only) - AWS CodeDeployAfter editing the AppSpec file, trigger a new deployment, and the network settings will be applied. The new ECS tasks in the green environment should start with the specified network configuration.Once the deployment is complete, you can safely remove the NetworkConfiguration from the AppSpec file.As described, even for Amazon ECS services using blue/green deployment with CodeDeploy, you can change the network settings by editing the AppSpec file and triggering a new deployment.I almost ended up recreating the ECS service because I wasn't aware of this method. I hope this article helps those in a similar situation.

How to Change Network Configurations for Blue/Green Amazon ECS Services

2024-10-18ENECHANGE Tech Talk（社内勉強会）

40代後半で開発エンジニアからクラウドインフラエンジニアにキャリアチェンジし、生き残れる自信がようやく持てた話

2024-09-25ENECHANGE I/O Day LT⼤会（社内イベント）

DockerのマルチプラットフォームイメージをGitHub Actionsでビルドして公開する際に、参考にしたドキュメントと便利だったツール

2024-09-11今さら聞けない！ オフィス・開発でのAI活用https://urahara-agile.connpass.com/event/328607/

RAGもファインチューニングも使わない 素朴なAIチャットボットを職場に導入した結果

In this article, I’ll introduce an SLO error budget monitoring system that I built entirely using AWS services.This system is based on the multi-window, multi-burn-rate alerting method proposed in the Site Reliability Workbook. It sends alerts to Slack when the SLO error budget burn rate exceeds a certain threshold.expr: (        job:slo_errors_per_request:ratio_rate1h{job="myjob"} > (14.4*0.001)      and        job:slo_errors_per_request:ratio_rate5m{job="myjob"} > (14.4*0.001)      )    or      (        job:slo_errors_per_request:ratio_rate6h{job="myjob"} > (6*0.001)      and        job:slo_errors_per_request:ratio_rate30m{job="myjob"} > (6*0.001)      )severity: pageexpr: (        job:slo_errors_per_request:ratio_rate24h{job="myjob"} > (3*0.001)      and        job:slo_errors_per_request:ratio_rate2h{job="myjob"} > (3*0.001)      )    or      (        job:slo_errors_per_request:ratio_rate3d{job="myjob"} > 0.001      and        job:slo_errors_per_request:ratio_rate6h{job="myjob"} > 0.001      )severity: tickethttps://sre.google/workbook/alerting-on-slos/The Site Reliability Workbook recommends combining multiple time windows and burn rates to create more accurate alerts. For example, if you only alert based on a short time window, you may get too many false positives. On the other hand, if you rely on a longer time window, it may take too long for an alert to trigger or recover. By using both short and long windows, the system can generate more precise alerts.For more detailed explanations of this alerting method, I encourage you to check out the Site Reliability Workbook, which is available for free. Personally, I believe that strictly following these guidelines is the best way to monitor service reliability.The primary motivation behind this monitoring system was to solve the problem of "alert fatigue." As an operations engineer, I was constantly bombarded with alerts that didn’t actually require any action.Previously, we monitored CPU and memory usage metrics directly, which led to alerts even when the service itself was running smoothly. For example, we would receive a Slack alert if the CPU usage of a web server exceeded 90%, regardless of whether there were any issues with availability or latency.However, even if the CPU usage was high, if the service remained available and responsive, there was no need for intervention. Over time, receiving alerts for issues that didn't require action caused fatigue and increased the risk of missing critical alerts. Missing an important alert could damage service reliability and lead to a loss of users.To address this, I decided to focus only on critical indicators—such as availability and latency—and set up an SLO-based monitoring system that tracks the error budget burn rate.At first, I considered using third-party monitoring tools like New Relic or Datadog. However, after investigating these tools in early 2023, I found that it was either impossible or very difficult to implement the kind of SLO monitoring I needed with their existing features. I worked with support teams from both platforms, but we couldn't come up with a viable solution.On the other hand, by combining AWS services such as Amazon CloudWatch, I could implement the necessary monitoring and at a much lower cost—around $20 per month.Since most of our workloads are hosted on AWS, building the monitoring system directly on AWS made it easier to integrate everything into a single console. AWS also offers a high degree of flexibility in terms of combining services, giving us more room to scale and customize compared to third-party tools like New Relic or Datadog.Here’s an overview of the system’s architecture:Although it may look a bit complex at first glance, the core workflow is simple:EventBridge Scheduler triggers a Lambda function at regular intervals.The Lambda function runs an Athena query to aggregate ALB access logs.The results are stored in both CloudWatch custom metrics and RDS.CloudWatch composite alarms use these metrics to trigger alerts based on the SLO conditions.The Lambda function is triggered by EventBridge instead of an S3 file save event. This is because when there is heavy traffic, multiple log files are saved to S3, which could result in the aggregation process being run multiple times unnecessarily.We use RDS to store the aggregated results in order to reduce Athena scan costs. For more details on these optimizations and custom metric definitions, please refer to my presentation at JAWS PANKRATION 2024.Since we introduced this system, alert fatigue has significantly decreased. I personally noticed a reduction in the number of unnecessary alerts that required no action.Additionally, the development team has become more invested in the reliability of the services. Now, when an alert is triggered, the team takes the initiative to tune performance or even revise the SLOs when necessary.As of September 2023, this system is monitoring 7 services and 12 critical user journeys.To streamline operations, I developed an internal Terraform module that allows us to quickly accommodate additional monitoring requests from the development team. While the module itself is private, this is an actual example of its interface, which could be useful as a reference if you plan to implement a similar module.module "slomon" {  source = "git@github.com:enechange/terraform-modules.git//slomon-for-alb?ref=v0.53.0"  environment_name              = "prod-enechange"  alb_access_logs_s3_url        = local.alb_access_logs_s3_url  sns_topic_names_for_paging    = ["cto-incident-enechange"]  sns_topic_names_for_ticketing = ["cto-alert-enechange"]  critical_user_journeys = {    input1_submit = {      http_method     = "POST"      path            = "/try/input1_submit"      dashboard_order = 1      slo = {        availability_target   = 95.0        latency_p95_threshold = 4.0        latency_p50_threshold = 3.0      }    }  }}This Terraform module also includes Athena queries for analyzing historical data, allowing us to quickly set SLOs based on past performance.At present, this monitoring system meets all of our needs. However, if CloudWatch's Application Signals feature evolves to support the required conditions for SLO monitoring, this custom system may no longer be necessary. In that case, we would likely transition to a fully managed solution.Likewise, if New Relic or Datadog introduce features that support the kind of SLO monitoring we need, we may consider switching to them. These APM tools generally offer better capabilities for diagnosing root causes of performance degradation compared to CloudWatch.Ultimately, we will continue to assess the best solution for our needs and adapt our system as new tools and services emerge.In this article, I introduced an SLO error budget monitoring system that I built using AWS services only.By implementing this system, we were able to reduce alert fatigue and increase the development team’s focus on service reliability.I hope this article provides useful insights for those dealing with similar challenges around alert fatigue.

Implementing SLO Error Budget Monitoring with AWS Services Only

2024-09-06Cloud Operator Days Tokyo 2024https://cloudopsdays.com/closing/

Amazon CloudWatchでSLOを監視してみた　CODT 2024 クロージングイベント版

2024-08-24 - 2024-08-25JAWS PANKRATION 2024https://jawspankration2024.jaws-ug.jp/en/

Cost-Effective SLO Error Budget Monitoring with Athena and CloudWatch

Cloud Operator Days Tokyo 2024https://cloudopsdays.com/

Amazon CloudWatchでSLOを監視してみた

2024-06-14ENECHANGE Tech Talk（社内勉強会）

AWS Protonの概要

2024-05-28Cloud Security Day 2024https://www.wafcharm.com/jp/seminar/2024/cloudsecurityday2024/

ENECHANGEが実現した管理者の工数負担を削減しながらもAWSセキュリティを強化した方法とは

2024-05-22アーキテクチャを突き詰める Online Conferencehttps://findy.connpass.com/event/314782/

Web APIのAWS Lambda移行で工夫したこと

Key Resultにはアクションを置くべきでない？「OKRのKey Resultにはアクションを置くべきでない」との意見を目にします。Perdoo は Objective を達成するために必要な仮説であり、施策であるアクションのことを Initiative とよんでいる。OKR の利用において Key Result の内容が Initiative になってしまっているということがよくあるようです。Objective頻繁にバズるブロガーになるKey Results月に2回以上はてなブックマーク50以上の記事があるInitiatives月に20記事を...

OKRのKey Resultにはアクションを置いてもよい

2024年1月25日新経済連盟AIコミュニティ第3回会合

AIの活用状況と今後の展望

2024-03-07JAWS-UG コンテナ支部 #26 新春大LT祭りhttps://jawsug-container.connpass.com/event/307354/

ECS on FargateへのSeekable OCI導入レポート

2024-03-02JAWS DAYS 2024https://jawsdays2024.jaws-ug.jp/

サービスクォータ、ちゃんと監視してますか？

2024-02-20JAWS-UG東京 ランチタイムLT会 #8https://jawsug.connpass.com/event/308413/

AWS Well-Architected Toolで信頼性をレビューした結果

2024-01-26ENECHANGE Tech Talk（社内勉強会）

テックカンパニーとしてのENECHANGEの中期目標

AWS CodeBuildプロジェクトで「自動再試行の上限」を設定できるようになりました。https://docs.aws.amazon.com/codebuild/latest/usergui…

CodeBuildの失敗ビルドを自動的にLambdaで再試行する

2023-11-22Cloud Security Day 2023 〜先駆者に学ぶ AWSセキュリティベストプラクティス〜https://www.wafcharm.com/jp/seminar/2023/cloudsecurityday2023/

ENECHANGE社のAWSセキュリティ改革ストーリー

2023-10-18JAWS-UG SRE⽀部 #7 AWSでゆるSRE︕LT⼤会https://jawsug-sre.connpass.com/event/291843/

ALBのアクセスログをAthenaで分析してSLOをゆるく決める

2023-09-14みんなのPython勉強会#97https://startpython.connpass.com/event/294703/

ChatGPT in SlackでAI Slackbotを楽しく運用する

コールドスタートに4～5秒かかるPythonのLambdaコンテナ関数があり、改善策を調べていたら、AWS公式ブログに下記の記述を見つけました。AWS が提供するベースイメージは、Lambda サービスによってプロアクティブにキャッシュされます。つまり、ベースイメージは近くの別のアップストリームキャッシュにあるか、ワーカーインスタンスキャッシュにすでに存在しています。はるかに大きいにもかかわらず、キャッシュされないかもしれないサードパーティのベースイメージと比較するとデプロイ時間が短くなる可能性があります。コンテナイメージとしてパッケージ化された Lambda 関数の最適化 | A...

Lambdaコンテナ関数ではAWS提供ベースイメージを使う

AWS LambdaのPythonコードでBugsnagを使う際、デフォルトの「asynchronous=True」のままだと、通知が飛びませんでした。深く追ってはいませんが、非同期的な通知より先にLambda関数が終了してしまうのでしょう。「asynchronous=False」を指定したところ、意図どおり通知が飛ぶようになりました。以下、参考リソースです。By default, requests are sent asynchronously to BugSnag. If you would like to block until the request is done, y...

AWS LambdaのPythonコードでBugsnagを使う際は「asynchronous=False」にする

Terraformで、特定の条件下でのみブロックを指定したい場面があります。たとえば、AWS Budgetsの予算を示すaws_budgets_budgetでは、予算タイプによってcost_filterブロックの要否が異なります。条件ごとにリソースを定義してもよいのですが、テンプレートが冗長になりがちです。下記の例では、try関数を使って、必要なときのみcost_filterブロックを指定してみました。すっきりしていて読みやすく感じます。locals {  budgets = {    # RDSリザーブドインスタンスのカバレッジ予算。cost_filtersが必要    r...

Terraformのtry関数をdynamicブロックの作成条件に使う

「AWS App Runner Advent Calendar 2022」の5日目の記事です。はじめにApp Runnerの学習目的で、tDiaryをデプロイしてみました。実運用を想定したもので…

AWS App Runnerを学ぶためtDiaryをデプロイしてみる

Terraformのawsプロバイダが未対応のAWS Chatbot、awsccなら対応しているとのことで、試してみました。https://hi1280.hatenablog.com/entry/2022/08/06/191154既存のSlackチャネルをインポートするところから始めようと、ドキュメントを見たところ、下記のように書かれていました。Import is supported using the following syntax:$ terraform import awscc_chatbot_slack_channel_configuration.example &l...

awsccでChatbotのSlackチャネルをterraform importする

AWS Transfer Familyサーバーで、SETSTATコマンドを無視できるようになりました。2022年6月のことです。https://aws.amazon.com/jp/about-aws/whats-new/2022/06/aws-transfer-family-expands-server-configuration-options-set-clients/ファイルをアップロードするとき、ファイル転送クライアントは SETSTAT コマンドを発行してリモートファイルの属性を変更します。ただし、SETSTAT コマンドはオブジェクトストレージシステムと互換性がないため、...

AWS Transfer FamilyサーバーでSETSTATコマンドを無視する

AWS Transfer Familyのドキュメントに誤りがあったので、報告したら、直してもらえました。下記のアクセスポリシーが修正対象なのですが、どこが誤りか分かりますか。{    "Version": "2012-10-17",    "Statement": [        {            "Sid": "AllowListingOfUserFolder",            "Action": [                "s3:ListBucket"              ],            "Effect": "Allow...

AWS Transfer Familyのドキュメントの誤りを直してもらった

CodeBuildトリガーの実体はEventBridgeルールなんですね。ドキュメントにも書いてありました。CodeBuild は、ビルドトリガーに Amazon EventBridge ルールを使用しますhttps://docs.aws.amazon.com/ja_jp/codebuild/latest/userguide/trigger-create.htmlなので、TerraformのAWSプロバイダでトリガーを作る場合は、aws_codebuild_projectではなく、aws_cloudwatch_event_ruleやaws_cloudwatch_event_ta...

CodeBuildトリガーの実体はEventBridgeルール

運営中サービスで提供しているフィードの構文が正しいか気になったので、バリデータを探したところ、W3C Feed Validation Serviceが見つかりました。さっそく検証すると、下記の指摘が。Errorelement must be an RFC-822 date-timeWarningMissing atom:link with rel="self"item should contain a guid elementEnsure description precedes content:encodedpubDateの日時がRFC 822形式でなかっ...

W3C Feed Validation Serviceを使ってフィードを修正した

Terraform で list の末尾要素を参照するには、公式ドキュメントにある通り element 関数と length 関数を組み合わせます。To get the last element from the list use length to find the size of the list (minus 1 as the list is zero-based) and then pick the last element:> element(["a", "b", "c"], length(["a", "b", "c"])-1)c引用元：element - F...

Terraform で list の末尾要素を参照する

AWSがデジタルバッジの発行を始めたので、さっそく取得してみました。取得したのは以下2つのバッジです。2022年2月現在は、この「AWS Learning: Block Storage」と「AWS Learning: Object Storage」のみが存在します。https://www.credly.com/badges/5b9371f0-9c6c-413a-b099-1aff5dafbc17/public_urlhttps://www.credly.com/badges/3c35fc05-c3c1-4d82-b79a-250e5b4714cc/public_urlいずれのバッ...

AWSストレージのデジタルバッジを2つ取得した #AWSTraining

Elastic Beanstalk の CLI で使える eb deploy コマンド には --nohang オプションがあります。現時点ではなぜかドキュメントに書かれていないオプションですが、ヘルプに書かれています。$ eb --versionEB CLI 3.20.2 (Python 3.7.2)$ eb deploy --helpusage: eb deploy <environment_name> [options ...]Deploys your source code to the environment.positional argument...

eb deploy には --nohang オプションがある

AWS BugBust re:Invent Challenge とはAWS re:Invent 2021 のイベントとして AWS BugBust re:Invent Challenge が開催されました。簡単に言うと「指定されたバグを多く修正すると賞金や賞品がもらえるコンテスト」です。詳しくは AWS ブログの記事をご参照ください。https://aws.amazon.com/jp/blogs/news/help-make-bugbusting-history-at-aws-reinvent-2021/ 修正したバグの例ぼくもこのイベントに参加して 129 件のバグを修正...

AWS BugBust re:Invent Challenge で修正したバグの例と最終成績

問題「Amazonの採用面接」と「高度情報処理技術者試験の午後Ⅱ論述問題」の共通点は何か。15字以内で答えよ 解答例STAR形式で問われる（11字） 解説Amazonの採用面接には「行動に基づく面接」が含まれています。応募者は自身の経験を「どのような状況で、どのようなタスクを引き受け、どのような行動をし、どのような結果を得たのか」という順序で具体的に説明しなければなりません。一方、高度情報処理技術者試験の午後Ⅱ論述問題では下記の構成の出題がよく見られます。設問ア　あなたが携わった個別システム化構想の策定において、背景となった事業目標、事業戦略に掲げられてい...

「Amazonの採用面接」と「高度情報処理技術者試験の午後Ⅱ論述問題」の共通点は何か。15字以内で答えよ

東京リージョンを含め Graviton インスタンスが使えるリージョンであれば Elastic Beanstalk でも Graviton インスタンスが使えるようになりました。Release: Elastic Beanstalk supports AWS Graviton instance types based on 64-bit Arm architecture on November 24, 2021 - AWS Elastic BeanstalkElastic Beanstalk now offers support for Graviton on all of th...

Elastic Beanstalk で Graviton インスタンスが使えるようになった（東京リージョンでも）

Elastic Beanstalk の 2021-11-19 付のリリースにより、Ruby プラットフォームで Ruby 3 が使えるようになりました。Release: Elastic Beanstalk Amazon Linux platform updates on November 19, 2021 - AWS Elastic BeanstalkAdded a new platform branch, Ruby 3.0.Platform Version and Solution Stack NameAMILanguagePackage Manager...

Elastic Beanstalk の Ruby プラットフォームで Ruby 3 が使えるようになった

us-east-1 など 6 つのリージョンの Elastic Beanstalk で Graviton インスタンスが使えるようになりました。Release: Elastic Beanstalk supports first wave of Graviton gradual rollout on October 13, 2021 - AWS Elastic BeanstalkGraviton は AWS が開発した Arm ベースのプロセッサです。特に第 2 世代の Graviton2 は x86 ベースのインスタンスと比べる形でコストパフォーマンスの良さが強調されています。...

[追記あり] Elastic Beanstalk で Graviton インスタンスが使えるようになった（東京リージョンはまだ）

リリースチェッカーというサービスを個人で運営しています。先日、HTTPS化のため、Let's Encryptのサーバ証明書を導入しました。手順は簡単だったのですが、事前に準備しておけば、もっとスム…

Let's Encrypt導入前に準備すべきこと

エラーの原因と回避方法は「[Django]DjangoのテストをDEBUG=Trueで実行する」と同じです。状況が少し違ったので、新たな記事を書くことにしました。エラーが起きた状況Django …