ENECHANGE Developer Blog

エネルギークラウド事業部でバックエンドエンジニアをしている白坂です。2024年10月から Amazon ElastiCache for Valkey が利用できるようになったため、私たちのチームでも Redis から Valkey への移行を行いました。移行の背景Valkeyに移行した最大の理由は、インフラコスト削減です。ElastiCache Serverless を使えば 33%のコスト削減オンデマンドノードでも 20%のコスト削減aws.amazon.com加えて、以下のような理由も後押しとなりました。パフォーマンスの向上Redis OSSのAPI互換性があるため、コード変更は最小限ダウンタイムゼロでの移行も可能（ただし後述の通り条件あり）つまずいたポイント1. TerraformのAWSプロバイダのバージョンTerraform設定では以下のように AWSプロバイダ をv4.X にしていました。required_providers {  aws = {    source  = "hashicorp/aws"    version = "~> 4.0"  }}しかし、Valkeyに対応しているのはv5.73.0以降 です。Error: expected engine to be one of [redis], got valkeygithub.com2. シングルノード構成だとValkeyへの移行ができない私たちのプロダクトは、ElastiCache for Redisを使用し、オンデマンドノードによるシングルノード構成で運用していました。resource "aws_elasticache_cluster" "this" {  cluster_id                = "${var.resource_name_prefix}-cache"  engine                    = "redis"  node_type                 = var.cache_node_type  num_cache_nodes           = 1  parameter_group_name      = "default.redis6.x"  engine_version            = "6.2"  port                      = 6379  final_snapshot_identifier = "${var.resource_name_prefix}-cache-final-snapshot"  maintenance_window        = "sat:17:00-sat:20:00"   snapshot_window           = "15:00-17:00"  security_group_ids        = [aws_security_group.cache.id]  subnet_group_name         = aws_elasticache_subnet_group.this.name}この状態で、 redis を valkey に書き換えてterraform applyを実行したところ、以下のエラーが発生しました。Error: creating ElastiCache Cache Cluster (test-cache-name): operation error ElastiCache: CreateCacheCluster, https response error StatusCode: 400, RequestID: e7e1cc26-d236-4e2e-9b8f-5e4ed5fad9d3, InvalidParameterValue: This API doesn't support Valkey engine. Please use CreateReplicationGroup API for Valkey cluster creation.同様のエラーはマネジメントコンソールからエンジンを変更しようとした場合にも発生しました。aws_elasticache_cluster リソースでは Valkey への移行をサポートしていないため、シングルノード構成をやめてレプリケーショングループを作成することにしました。resource "aws_elasticache_replication_group" "this" {  replication_group_id       = "${var.resource_name_prefix}-rep-group"  description                = "ElastiCache for Valkey"  engine                     = "valkey"  engine_version             = "8.0"  automatic_failover_enabled = false  node_type                  = var.cache_node_type  parameter_group_name       = "default.valkey8"  port                       = 6379  apply_immediately          = false  maintenance_window         = "sat:17:00-sat:20:00"  snapshot_window            = "15:00-17:00"   notification_topic_arn     = "arn:aws:sns:ap-northeast-1:899381291843:${var.dev_monitoring_topic_name}"  subnet_group_name          = aws_elasticache_subnet_group.this.name  security_group_ids         = [aws_security_group.cache.id]}ElastiCacheはノード数毎に課金されるため、レプリケーショングループを作成してもクラスターモードを disabled にしてノード数を１つにすれば、シングルノード構成と料金は変わりません。私たちのプロダクトでは、運用中にElastiCacheのデータが消失することやダウンタイムの発生が許容されるため、既存のRedisノードを削除し、新たにValkey用のレプリケーショングループを構築する方針にしました。3. アプリケーションコードの変更は必要なかった私たちのプロダクトはPython + Django + Celery 構成で、Redisを以下の用途で使用していました。CeleryのブローカーCeleryのバックエンドDjangoのキャッシュバックエンド結果としてコードの修正は不要でした。Redis URL（redis://）をそのまま使うことができるdjango-redisやredis-py、Celeryもそのままで動作するですが、将来的にValkeyが独自機能を追加していく可能性があるため、django-valkeyやvalkey-pyへの移行も検討しておいた方が良さそうです。valkey-glide というライブラリも使えそうです。その他また、今回 Redis6.2 から Valkey8.0.1 にアップデートしているため、下記のリリースノートを確認しました。github.comgithub.comdocs.aws.amazon.comまとめValkey8.0 でさらなるパフォーマンス向上がされているようなので、RedisからValkeyへの移行はメリットが大きいと感じています。Redis7.4以降はValkeyとの互換性がなくなってしまうため、Redisから早めに移行しておいた方が良さそうです。

ElastiCache for RedisをValkeyへ移行しました

ENECHANGEの Yuto Ono です。普段はフロントエンド開発をメインでやっていますが、最近、新規プロダクト開発に伴い、 Terraform でのインフラ構築を経験しました。面白い経験ができたと感じたので、その時に感じたことを書いていきたいと思います。AWSの資格取得で学んだことを実践できたTerraform の基礎が身についたTerraform Modules の偉大さを実感したCTO室の手厚いサポートさいごにAWSの資格取得で学んだことを実践できた僕は2024年2月に、AWS Solutions Architect - Associate (SAA) という試験を受け、無事に合格しました。おかげで既存サービスのインフラ構成への理解は深まったものの、身につけた知識を存分に活かしているとは言えない状況でした。それから2025年に入り、新規プロダクトのインフラ構築を担当することになり、ついにAWSの知識を活かせるチャンスが来たと思いました。AWSの勉強をしておいたおかげで、 ECS, Fargate, CodePipline など、スムーズに理解でき、構築が捗りました。あのとき勉強しておいて本当に良かったと思いました。Terraform の基礎が身についた最初は、よくわからないまま、なんとなく plan や apply といったコマンドを実行していましたが、色々と調べる中で、大事なことに気づくことができました。コード上のリソースとAWS上のリソースの紐づけを記録する、 tfstate の概念について知ったことで、だいぶ Terraform に対する解像度が上がりました。↓ こちらの記事等を参考にさせていただきました。ありがとうございます。zenn.devまた、今回のことをきっかけにIaCに興味を持ったことで、下記のような技術書を購入して体系的に学び始めました。［詳解］AWS Infrastructure as Code――使って比べるTerraform＆AWS CDK エンジニア選書作者:原 旅人技術評論社AmazonTerraform Modules の偉大さを実感したENECHANGEでは、 Terraform Modules を活用し、複数プロジェクトで汎用的に使えるインフラ構成を共通化しています。そのおかげで、最低限の記述でスピーディに構築できるようになっており、感動しました。なお、既存の Terraform Modules では実現できないことに遭遇し、そのたびにCTO室に相談し、ときにはモジュール側を変更いただき、新バージョンとして提供いただきました。CTO室の皆さんには柔軟に対応いただきありがたかったのと、結果的に社内のモジュールを育てていくことに貢献できて嬉しかったです。CTO室の手厚いサポートCTO室のエンジニアにいつでも相談できる環境だったので、安心して進めることができました。質問を投げると、インフラについての知見をお持ちの複数名のエンジニアから回答をいただけました。しかも、回答が早かったので、すごく助かりました。ときには、自分でどうしても解決できない・解決に時間がかかる問題について、CTO室のエンジニアに介入いただき助けてもらったこともありました。非常に心強かったです。さいごにENECHANGEでは、僕に限らず、アプリケーション開発を担当するエンジニアが、インフラ構築・運用を経験できるチャンスが多いと感じます。積極性があれば、色々な分野を経験し幅を広げることができる弊社の環境は魅力的だと思います。興味を持ってくださった方は、ぜひENECHANGEの採用情報をご確認ください！engineer-recruit.enechange.co.jp

フロントエンドエンジニアだけどインフラ構築をやってみた

CTO室の岩本 (@iwamot) です。ENECHANGEでは、Amazon ECRの拡張スキャンを全社的に導入しました。OSパッケージの脆弱性のみが対象となる基本スキャンと違い、プログラミング言語パッケージも対象となります。導入の狙いは、セキュリティの強化と開発者体験の向上です。古いバージョンのOSやプログラミング言語が使われつづけると、安全性だけでなく開発者のモチベーションまで低下してしまいかねません。ただし実際に導入してみると、始める前に知っておきたかったポイントがありました。この記事では、これからECRの拡張スキャンを使う方に向けて、とくに押さえておきたい2つの設定を紹介します。1. Amazon InspectorではなくAmazon ECRから有効化すべしECRの拡張スキャンにはAmazon Inspectorが使われますが、有効化する方法によって設定内容が大きく変わります。これが1つめのポイントです。Inspectorをアクティブ化すると過剰な設定になりがちまず、シンプルにInspectorをアクティブ化するとどうなるか見てみましょう。下図のようにECRの拡張スキャンは有効になるものの、Amazon EC2やAWS Lambdaのスキャンまで有効になってしまいます。ECRの拡張スキャンのみ必要な場合、この方法は避けるべきです。さらに、ECRでは全リポジトリが連続スキャンの対象となってしまいます。既存のイメージが意図せずスキャンの対象となり、大量のイメージを保持している環境では利用料金が跳ね上がりかねません。ECRのスキャン設定から有効化すれば十分そうではなく、ECRのスキャン設定で拡張スキャンを有効化することをおすすめします。最初はリポジトリを絞って、プッシュ時の脆弱性検出を試せば十分でしょう。Inspectorによるスキャンがすべて無効化された状態から始めれば、ECRの拡張スキャンだけが有効になります。以上のようにプッシュ時の拡張スキャンだけを有効化し、様子を見ながら対象を拡げていくのがおすすめです。2. 通知をカスタマイズして見やすくすべしせっかく拡張スキャンを有効にしたのであれば、検出結果を通知したいところです。ENECHANGEでは、Amazon EventBridgeに送信されるイベントをAmazon Q Developer in chat applications（旧称：AWS Chatbot）経由でSlackに通知することにしました。よくある構成です。しかしデフォルトのままだと、通知内容が分かりづらくて実用的ではありません。特につらいのは、イメージタグと脆弱性が含まれていない点です。それぞれがぱっと分からないと、対応の勘所がつかみにくくなります。そこで、EventBridgeの入力トランスフォーマーを使って通知内容をカスタマイズすることにしました。送信されるイベントの詳細は「Amazon Inspector 検出結果イベントスキーマの例」に書かれています。具体的なカスタマイズ内容は下記のとおりです。入力パス{  "account": "$.account",  "detailType": "$.detail-type",  "findingArn": "$.detail.findingArn",  "imageHash": "$.detail.resources[0].details.awsEcrContainerImage.imageHash",  "imageTag": "$.detail.resources[0].details.awsEcrContainerImage.imageTags[0]",  "pushedAt": "$.detail.resources[0].details.awsEcrContainerImage.pushedAt",  "region": "$.region",  "repositoryName": "$.detail.resources[0].details.awsEcrContainerImage.repositoryName",  "title": "$.detail.title"}入力テンプレート{"content":{"description":"<findingArn>\n\n*Image:* <repositoryName>:<imageTag>\n*Vulnerability:* <title>","textType":"client-markdown","title":":warning: <detailType> | <region> | Account: <account>"},"metadata":{"threadId":"<imageHash>|<pushedAt>"},"source":"custom","version":"1.0"}これにより、下記の項目が通知に含まれるようになりました。Inspectorの検出結果ARN (<findingArn>)イメージタグ (<repositoryName>:<imageTag>)検出された脆弱性 (<title>)また、同じイメージの検出結果がスレッドにまとまるようにスレッドIDを調整しています (<imageHash>|<pushedAt>)。以上が、2つめの設定ポイントです。カスタマイズにより通知が見やすくなりました。拡張スキャン導入の効果以上の工夫により、ENECHANGEではクリティカルな脆弱性に対応できるようになりました。下記は実際におこなった対応の一例です。ベースイメージのアップデートにより脆弱性を解消しています。アプリケーションのDockerイメージ-FROM ruby:3.2.2-slim-bullseye +FROM ruby:3.4.1-slim-bookwormログ集約基盤のDockerイメージ-FROM public.ecr.aws/aws-observability/aws-for-fluent-bit:2.28.0 +FROM public.ecr.aws/aws-observability/aws-for-fluent-bit:2.32.5工夫しながらECRの拡張スキャンを導入したことで、セキュリティがスムーズに強化できるようになったと手応えを感じています。まとめAmazon ECRの拡張スキャンは、セキュリティを強化するうえで有用です。ただし、現時点で快適に運用するには今回ご紹介したような工夫が必要となります。Amazon InspectorではなくAmazon ECRから有効化すべし通知をカスタマイズして見やすくすべし以上、導入を検討している方の参考になれば幸いです。

Amazon ECRの拡張スキャンを始める前に知っておきたい設定ポイント2つ

こんにちは、cto室のldrです。Terraform v1.11.0でGAとなった機能の1つであるS3 Native State Lockingついて書きたいと思います。v1.11.0S3 native state locking is now generally available. The use_lockfile argument enables users to adopt the S3-native mechanism for state locking. As part of this change, we've deprecated the DynamoDB-related arguments in favor of this new locking mechanism. While you can still use DynamoDB alongside S3-native state locking for migration purposes, we encourage migrating to the new state locking mechanism.S3バックエンドによる状態管理DynamoDBTerraformは、stateをAmazonS3の特定のバケット内の特定のキーに保存します。このバックエンドは、状態ロック機能もサポートしており、今までは専用のDynamoDBテーブルを用いて、ロックの取得、解放、タイムアウトなどをDynamoDBのレコードで制御していました。terraform {  backend "s3" {    bucket = "mybucket"    key    = "path/to/my/key"    region = "us-east-1"    dynamodb_table = "state-locking"  }}S3 native state lockingS3バックエンドにおいて、状態ファイルと同じバケットにロック用のファイル（通常は拡張子 .tflock）を作成し、ロック状態を管理するようになりました。設定としてはuse_lockfile引数をtrueに設定することで有効化できます。use_lockfile - (Optional) Whether to use a lockfile for locking the state file. Defaults to false.terraform {  backend "s3" {    bucket = "mybucket"    key    = "path/to/my/key"    region = "us-east-1"    use_lockfile = true  }}必要なIAM権限S3バケットに対して必要な権限s3:ListBucket: バケット上で状態が保存されるパスをリストできる必要があります。s3:GetObject: 状態ファイルの読み書きが必要です。s3:PutObject: 状態ファイルの読み書きが必要です。s3:DeleteObjec: ロックファイルを利用する場合に必要です。{  "Version": "2012-10-17",  "Statement": [    {      "Effect": "Allow",      "Action": "s3:ListBucket",      "Resource": "arn:aws:s3:::mybucket",      "Condition": {        "StringEquals": {          "s3:prefix": "mybucket/path/to/my/key"        }      }    },    {      "Effect": "Allow",      "Action": ["s3:GetObject", "s3:PutObject"],      "Resource": [        "arn:aws:s3:::mybucket/path/to/my/key"      ]    },    {      "Effect": "Allow",      "Action": ["s3:GetObject", "s3:PutObject", "s3:DeleteObject"],      "Resource": [        "arn:aws:s3:::mybucket/path/to/my/key.tflock"      ]    }  ]}

Terraform v1.11.0のS3 Native State Lockingについて

こんにちは、CTO室のldrです。GitHub CI/CD実践ガイドの著者が提唱するグッドプラクティスを実践し、1つ追加してみました。グッドプラクティス11タイムアウトを常に指定するデフォルトシェルでBashのパイプエラーを拾う「actionlint」ですばやく構文エラーをチェックするConcurrencyで古いワークフローを自動キャンセルする不要なイベントで起動しないようにフィルタリングする最安値のUbuntuランナーを優先するGITHUB_TOKENのパーミッションはジョブレベルで定義するアクションはコミットハッシュで固定するBashトレーシングオプションでログを詳細に出力するworkflow_dispatchイベントで楽に動作確認するワークフローの背景情報をコメントへ書き残す+1OIDCとAWSSTSを使用した認証を使用するPR作成時にterraform [validate,plan]を実行するworkfllowを作成1.タイムアウトを常に指定するすばやく失敗を検出し、効果的にフィードバックを得ることが大切GitHub Actionsのデフォルトタイムアウトは360分なので、意図しない通信障害に気づかないと半日実行し続けてしまいますね。VPC含むNetworkをまるっと作成するPlanも発生するのでタイムアウトは10分にしました。ジョブに記述timeout-minutes: 102.デフォルトシェルでBashのパイプエラーを拾うパイプ処理中のエラーを無視します。エラー時に意図せず処理を継続するため、結果として不具合の温床になります。GitHub ActionsではBashの利用を明示的に宣言すると、なぜかpipefailオプションが有効化されますパイプ（|）を使ったコマンドの実行中に、途中のコマンドでエラーが発生しても、そのまま処理が続行されてしまうのですが、Bashの利用を明示的に宣言しておくことで、pipefailオプションが有効化になってパイプ処理中のエラーを確実に検出し、意図しない処理の継続を防ぎます。例：bashスクリプトでのpipefailオプションの有効化set -o pipefailジョブに記述defaults:  run:    shell: bash3.「actionlint」ですばやく構文エラーをチェックする.github/workflowsディレクトリ配下のYAMLファイルをまとめてチェックし、構文エラーや非推奨構文などを検出します- .github/workflowsディレクトリ配下にactionlintを作成しますActionlint Checkname: 'Actionlint Check'on:  push:    branches:      - '**'  pull_request:    branches:      - 'develop'jobs:  actionlint:    name: 'Actionlint'    runs-on: ubuntu-latest    timeout-minutes: 10    steps:      - name: Checkout Repository        uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2      # docker runを使用してactionlintを実行する      - name: RunActionlint        run: |          set -x          docker run --rm -v "${{ github.workspace }}:${{ github.workspace }}" -w "${{ github.workspace }}" rhysd/actionlint:latest4.Concurrencyで古いワークフローを自動キャンセルするプルリクエストで起動するワークフローは、最新コード以外での実行がたいてい不要です。自動テストや静的解析はその典型で、古いコードで実行されるワークフローはムダです。プルリクエストが更新されるたびにワークフローが実行されると、古いコードに対してもワークフローが動いてしまいます。しかし、自動テストや静的解析の目的は「最新のコードが問題ないかを確認すること」なので、過去のコミットに対するワークフローの実行は無駄になります。ワークフロー全体に対して汎用的な設定を記述# PRで最新のコードだけを実行対象group: pr-${{ github.event.pull_request.number }}# pushも含む汎用的group: ${{ github.workflow }}-${{ github.ref }} # 古いワークフローを自動キャンセルし、リソースを節約concurrency:  group: ${{ github.workflow }}-${{ github.ref }}  cancel-in-progress: true5.不要なイベントで起動しないようにフィルタリングするpull_requestイベントやpushイベントなら、ファイルパスやブランチで起動条件を調整可能ですイベントに記述on:  pull_request:    paths: '**.tf'6.最安値のUbuntuランナーを優先するGitHub Actionsは使用時間に応じて課金されます。この使用時間はワークフローの実行時間へ、ランナーごとに設定されている乗率をかけて計算します。「使用時間」＝「実行時間」×「ランナーごとに異なる乗率」この乗率はUbuntuランナーがもっとも小さいです。ジョブに記述runs-on: ubuntu-latest7.GITHUB_TOKENのパーミッションはジョブレベルで定義するGITHUB_TOKENの権限はパーミッションで制御し、最小権限での運用が鉄則です。ワークフロー全体に対して記述permissions:  contents: read8.アクションはコミットハッシュで固定するGitタグは可変です。攻撃者がコードを改ざんしてGitタグも上書きすれば、アクション経由でワークフローを侵害できますstepに記述uses: hashicorp/setup-terraform@b9cd54a3c349d3f38e8881555d616ced269862dd # v3.1.29.Bashトレーシングオプションでログを詳細に出力するデバッグの第一歩は、なにが起きているか把握することです。そこで役立つのが、Bashのトレーシングオプションです。stepに記述set -x10.workflow_dispatchイベントで楽に動作確認するworkflow_dispatchイベントは起動タイミングが自由なだけでなく、任意のブランチで起動可能です。つまりデフォルトブランチへマージする前に、ワークフローの動作確認ができます手動実行が必要なため、CI/CDパイプライン全体の自動化フローが乱れる可能性もあると思ったので採用を見送りました。11.ワークフローの背景情報をコメントへ書き残すあなたが実装したワークフローは、他人にとって自明ではありません。拝承いたします。+1.OIDCとAWS STSを使用した認証を使用するシークレット変数でアクセスキーとシークレットキーを運用するのではなく、OIDCを使用することでAWS STSと連携する。permissions:  id-token: write- name: Configure AWS Credentials via OIDC  uses: aws-actions/configure-aws-credentials@ececac1a45f3b08a01d2dd070d28d111c5fe6722 # v4.1.0  with:    role-to-assume: arn:aws:iam::xxxxxxxxx:role/github-actions-role    aws-region: ap-northeast-1グッドプラクティス11+1を適用したワークフローTerraform PRname: 'Terraform PR Validate'on:  pull_request:    paths: '**.tf'    branches:      - 'develop'permissions:  contents: read  id-token: write  # OIDCトークン発行権限# 古いワークフローを自動キャンセルし、リソースを節約concurrency:  group: ${{ github.workflow }}-${{ github.ref }}  cancel-in-progress: truejobs:  terraform:    name: 'TerraformValidateonChangedDirectories'    runs-on: ubuntu-latest    timeout-minutes: 10    env:      AWS_DEFAULT_REGION: 'ap-northeast-1'    defaults:      run:        shell: bash    steps:      # 1. PRの最新コミットをチェックアウト      - name: CheckoutRepository        uses: actions/checkout@@eef61447b9ff4aafe5dcd4e0bbf5d482be7e7871 # v4.2.        with:          ref: ${{ github.head_ref }}      # 2. AWS認証情報の設定（OIDC経由でIAMロールを引き受ける）      - name: Configure AWS Credentials via OIDC        uses: aws-actions/configure-aws-credentials@ececac1a45f3b08a01d2dd070d28d111c5fe6722 # v4.1.0        with:          role-to-assume: arn:aws:iam::xxxxxxxxx:role/github-actions-role          aws-region: ap-northeast-1      # 3. Terraform CLIのセットアップ      - name: SetupTerraform        uses: hashicorp/setup-terraform@b9cd54a3c349d3f38e8881555d616ced269862dd # v3.1.2        with:          terraform_version: '1.11.0'      # 4. PRのターゲットブランチをフェッチ      - name: FetchBaseBranch        run: |          set -x          git fetch origin ${{ github.base_ref }}      # 5. 変更された*.tfファイルが含まれるディレクトリを抽出      - name: ListChangedTerraformDirectories        id: list_dirs        run: |          set -x          changed_dirs=$(git diff --name-only origin/${{ github.base_ref }} HEAD | grep '\.tf$' | xargs -n1 dirname | sort -u)          echo "ChangeddirectorieswithTerraformfiles:"          echo "$changed_dirs"          {            echo "dirs<<EOF"            echo "$changed_dirs"            echo "EOF"          } >> "$GITHUB_OUTPUT"      # 6. 変更された各ディレクトリでTerraformの初期化と検証を実行（-backend=falseで状態取得をスキップ）      - name: TerraformValidateinChangedDirectories        run: |          set -x          IFS=$'\n' read -r -a dirs <<< "${{ steps.list_dirs.outputs.dirs }}" || true          if [ ${#dirs[@]} -eq 0 ]; then            echo "NochangedTerraformdirectoriesfound."          else            for d in "${dirs[@]}"; do              echo "Processingdirectory:$d"              (cd "$d" && terraform init -backend=false && terraform validate)            done          fi

GitHub CI/CD実践ガイドの著者の記事を写経してグッドプラクティス11を学び、+1してみる

CTO室の岩本 (@iwamot) です。2025年3月1日に開催されたJAWS DAYS 2025で「開発組織を進化させる！ AWSで実践するチームトポロジー」と題する発表をしました。CfPに応募した理由は下記の通りです。書籍『チームトポロジー』を読み、エンジニアリングでの迷いが減ったAWSユーザーとしてENECHANGEで進めてきた取り組みが、チームトポロジーの考え方に（偶然にも）沿っていることに気づいたこの経験を整理してシェアすれば、他のAWSユーザーの迷いも減らせるのではないかと考えた発表後、聴いてくださった方から「チームトポロジー、読んでみます」「ちょうど進めようと思っていたので参考になりました」と声をかけていただけました。ありがたいかぎりです。いずれアーカイブ配信があるはずなので、そちらもお楽しみいただければ幸いです。以下、写真など。登壇直前に撮っていただいた記念写真ENECHANGE、ランチサポーターで参加しております。巾着、クリアファイル、木製うちわをご用意しております🦈おかげさまで、ウエットティッシュは終了しました🙇#jawsdays2025 #jawsug pic.twitter.com/jcI54zlyMz— Takashi Iwamoto (@iwamot) 2025年3月1日   スタンプ王、コンプリートしたよ！#jawsdays2025 #jawsug pic.twitter.com/eqYuscaCs4— Takashi Iwamoto (@iwamot) 2025年3月1日   このあとウルトラクイズにも参加します🗽#jawsdays2025 #jawsug— Takashi Iwamoto (@iwamot) 2025年3月1日   実は画伯 (?) としても参加しておりました。ありがたく持ち帰ります🖍️#jawsdays2025 #jawsug pic.twitter.com/ow3ORT2mmN— Takashi Iwamoto (@iwamot) 2025年3月1日   いただいたグッズの一部を並べて撮影後、セゾンテクノロジーさんのクリアファイルが上下逆であることに気づきました。すみません🙇（並べ直す気力がない…）#jawsdays2025 #jawsug pic.twitter.com/jCYFKLUymy— Takashi Iwamoto (@iwamot) 2025年3月1日   10月11日のJAWS FESTA 2025 in Kanazawaでも、お会いしましょう！

JAWS DAYS 2025のセッション「開発組織を進化させる！ AWSで実践するチームトポロジー」で登壇しました

こんにちは、cto室のldrです。terraform v1.11.0がリリースされ、注目してた機能が実装されましたのでご紹介したいと思います。新機能書き込み専用属性の追加プロバイダー側でリソースの属性を「書き込み専用」として指定できるようになりました。terraform testのJUnit XML出力オプションの一般提供terraform testコマンドに-junit-xmlオプションが利用可能になりました。S3ネイティブ状態ロックの一般提供S3を利用した状態ロック機能がuse_lockfile引数を使うことで有効化できるようになり、DynamoDB関連の引数は非推奨となりました。今回は書き込み専用属性の追加について触れたいと思います。簡単に言うと、Terraformがリソース作成時に機密情報を一時的に渡すための仕組みです。用途RDSの初回作成時に一時的なパスワードを渡し、Terraformの状態に機密情報が残らないようにし、その後は外部のシークレット管理システム（AWSSecretsManager）で運用するケースがまずは思い浮かびます。実装利用できるプロバイダーのバージョンは5.89ですterraform {  required_version = "~> 1.11.0"  required_providers {    aws = {      source  = "hashicorp/aws"      version = "~> 5.89"    }  }}password_woでephemeralを参照し、password_wo_versionでバージョンを定義します。作成されたパスワードはもちろんoutputでもdataでも参照できません。ephemeral "random_password" "password_wo" {  length = 16}resource "aws_db_instance" "password_wo" {// 省略password_wo            = ephemeral.random_password.password_wo.resultpassword_wo_version    = 1lifecycle {  ignore_changes = [password_wo]}tfstateには文字列リテラルでなく、nullとして記述されるようになっています。password_wo_versionの値は定義されますので、ephemeralでパスワードを運用していく場合はpassword_wo_versionをインクリメントしていく必要があります。"password": null,"password_wo": null,"password_wo_version": 1,想定する運用方法flowchart TD    A[Terraform: password_woとpassword_wo_versionで初期パスワード作成]    B[Terraform: lifecycleでignore_changesを設定]    C[初期パスワード適用 (tfstateにはパスワードが保存されない)]    D[SecretsManagerに新パスワード登録]    E[IAM認証でサーバにログインしてパスワード変更]    F[最終的にtfstateに機密情報が残らず、差分も発生しない]    A --> B    B --> C    C --> D    D --> E    E --> F

Terraform v1.11.0のWrite-Only Attributesについて

ENECHANGEの白坂です。2024年9月27日〜29日に開催されたPyCon JP 2024に参加してきたので、イベントの様子や印象に残ったセッションについてご紹介します。ゴールドスポンサーになりました！印象に残ったセッション5年分のツケを一気に払った話Rustを活用したPythonライブラリの開発WEBアプリケーションにおけるAWS Lambdaを用いた大規模な非同期処理の実践最後に2024.pycon.jpゴールドスポンサーになりました！今年、弊社はゴールドスポンサーとしてPyCon JP 2024に参加しました！去年に続き、スポンサーブースを出展し、多くの方々と交流することができました。想像以上に多くの方がEVに乗った経験があることに驚きました。アンケートにご回答いただいた方にはハンディファンやトートバッグを配布しました28日の夜には、スポンサーや登壇者限定のパーティーに参加しました。pyconjp-staff.connpass.com印象に残ったセッション5年分のツケを一気に払った話Pythonやサードパーティライブラリのアップデートを長期間していなかったシステムで、バージョンを一度に上げた結果、多くの問題が発生した事例が紹介されていました。後回しにされがちなライブラリのアップデートですが、こうした事例を目の当たりにすると、やはり定期的なメンテナンスの重要性を感じました。ライブラリアップデートを実施しました。 speakerdeck.comRustを活用したPythonライブラリの開発pydantic v2などRust製のPythonライブラリがどのようにして作られているのか、その内部的な仕組みを解説されていました。docs.google.comWEBアプリケーションにおけるAWS Lambdaを用いた大規模な非同期処理の実践ビープラウドさんのシステムで大量のメール送信の処理時間を短くするために、既存のアーキテクチャからAWS SQS + Lambdaを使ったアーキテクチャに移行したという内容でした。amazon-sqs-python-extended-client-libというライブラリで解消したとのことでした。 speakerdeck.com最後に2025年のPyCon JPは広島開催とのことです。普段交流できない方々と出会える貴重な機会なのでまた参加したいです。弊社では、社員のカンファレンス参加を積極的に推奨しております。弊社にご興味をお持ちいただけましたら、ぜひ以下のページもご覧ください。engineer-recruit.enechange.co.jp

PyCon JP 2024参加レポート

ENECHANGEの白坂です。普段はバックエンド開発をメインでしています。今回の記事では、ライブラリアップデートの具体的な実施手順と、継続的にアップデートを実施していくための工夫を紹介します。ライブラリアップデートはなぜ必要なのか？ライブラリアップデートが必要な理由1. 開発が止まるリスクを避けるため2. 脆弱性に対応するため3. 迅速に脆弱性に対応できるようにするため4. ライブラリの新機能を使うため脆弱性対応が遅れると発生するリスクEquifax社のデータ漏洩（2017年）Log4Shell（2021年）ライブラリアップデートどうやって進める？実施手順1. 全てのtestをpassさせて、warningsを0に近づける2. 使っていないライブラリの削除3. 使っていないコードと関連ライブラリの削除4. 最も古い＆影響範囲の狭いライブラリのバージョンアップ5. その他のライブラリのバージョンアップ6. poetry update継続的に実施するための取り組み1. タスクと工数を可視化する2. Dependabotの導入Dependabotでライブラリアップデートを一部自動化しようDependabotとは？1. Dependabot alerts2. Dependabot security updates3. Dependabot version updates設定方法ライブラリの脆弱性アップデートPRがパッチバージョンだった場合にオートマージする最後に参考記事ライブラリアップデートはなぜ必要なのか？ライブラリアップデートが必要な理由ライブラリアップデートってついつい後回しになってしまいますよね。私たちのチームのプロダクトは運用が始まって10年程なのですが、ライブラリアップデートは後回しにされがちで、普段開発していても、「ライブラリが古すぎてある日急にコードが動かなくなる」ということが定期的に起こっていました。こうした状況をなんとかして変えたいという思いがあり、まずはライブラリアップデートがなぜ必要なのかを言語化してみました。開発が止まるリスクを避けるため脆弱性に対応するため迅速に脆弱性に対応できるようにするためライブラリの新機能を使うため1. 開発が止まるリスクを避けるためライブラリが古いままだと、開発が想定外のトラブルで停止するリスクがあります。実際に私たちのチームで起こっていたので、体感としてすぐ理解できました。具体的には「昨日まで動いていたコードが動かなくなった」、「新しいライブラリを追加したくてもできない」等です。新機能を開発するために工数を見積もっても、このような事態が起こると予定工数やスケジュールが崩れます。そのため、工数見積もりやスケジュールの精度を上げたり、開発者体験向上のためにも、別工数でライブラリアップデートを定期的に実施して、開発が止まるリスクを避けるべきだと思いました。2. 脆弱性に対応するためライブラリは常に新しい脆弱性が発見されています。そのまま放置すれば、セキュリティリスクが高まり、システムが攻撃される可能性が大きくなります。私たちのチームでは、ライブラリの脆弱性管理にDependabotを使っているのですが、結構な頻度で脆弱性の通知が発生するので、定期的なライブラリアップデートがいかに必要か実感しています。3. 迅速に脆弱性に対応できるようにするため2だけだと、「脆弱性対応が必要なライブラリだけアップデートすればいい」という考えになりがちですが、そうではありません。他のライブラリが古いままだと、重大な脆弱性を修正したバージョンに依存関係が対応できず、結果として脆弱性対応が遅れることがあります。そのため全てのライブラリを定期的に最新に近づける必要があります。zenn.dev4. ライブラリの新機能を使うためライブラリの新しいバージョンには、新機能や改善が含まれています。これらを活用することで、より効率的で保守性の高いコードを書けるようになります。場合によっては、パフォーマンスの向上も期待できます。zenn.dev脆弱性対応が遅れると発生するリスク重大な脆弱性対応が遅れることがどのくらいリスクなのか、実はあまりよく分かっていないので調べてみました。過去には下記のようなインシデントが起こっています。Equifax社のデータ漏洩（2017年）米国の信用情報会社Equifaxは、Apache Strutsの脆弱性（CVE-2017-5638）を悪用され、約1.5億件の個人情報が漏洩しました。原因は、サードパーティライブラリであるApache Strutsの脆弱性が公表されていたにもかかわらず、Equifaxが人為的ミスでパッチバージョンを適用しなかったためです。このインシデントによって、多額の補償金が発生し、株価も暴落しました。www.scientia-security.orgwww.itmedia.co.jpLog4Shell（2021年）Javaのロギングライブラリ「Log4j」における重大な脆弱性（CVE-2021-44228）が発見され、世界中の多くのシステムやサービスに影響を与えました。www.issoh.co.jppiyolog.hatenadiary.jpライブラリアップデートどうやって進める？上記理由をメンバーに説明し、これまで後回しにされてきたライブラリアップデートに着手することができました。以下に具体的な実施手順をまとめます。実施手順私たちのプロダクトはPythonコードで書かれており、poetryを使っています。そのため、poetryでの具体的な手順をまとめます。全てのtestをpassさせて、warningsを0に近づける使っていないライブラリの削除使っていないコードと関連ライブラリの削除最も古い＆影響範囲の狭いライブラリのバージョンアップその他のライブラリのバージョンアップpoetry update1. 全てのtestをpassさせて、warningsを0に近づける現状のプロダクトだと、testが全てpassせず、warningsが数万件出ている状態だったので、いったんこれらを解消しました。failedやwarningsが0に近ければ近いほど、ライブラリアップデートの影響を早期に発見しやすくなります。2. 使っていないライブラリの削除poetryファイルに記載されているものの、コード上では使用されていないライブラリがあったため削除しました。コード上で使われていないことを確認するために deptry が便利です。poetry add deptrypoetry run deptry .pyproject.toml: DEP002 'simplejson' defined as a dependency but not used in the codebasepyproject.toml: DEP002 'ipython' defined as a dependency but not used in the codebasepyproject.toml: DEP002 'deptry' defined as a dependency but not used in the codebaseこんな感じでコード上で使われていないライブラリを一発で洗い出してくれます。※コード上では使われていなくても、デバッグ用などで使われている場合もあるので、ライブラリを実際に削除する際は慎重に確認しましょう。3. 使っていないコードと関連ライブラリの削除コード上ではライブラリが使われていても、そもそもそのコード自体が使われていないということがあったので、そういったコードやライブラリもこれを機に削除しました。4. 最も古い＆影響範囲の狭いライブラリのバージョンアップいまだにライブラリのアップデートができていませんが、ようやくここでライブラリのアップデートです。アップデートする際の順番は、バージョンが最も古いもの、かつ、影響範囲の狭い（使われている箇所が少ない）ライブラリを優先すべきだと思いました。バージョンが新しいライブラリから先に上げようとすると、古いライブラリとの依存関係がなくてエラーになることが多かったためです。また、使われている箇所が少ないライブラリは、3に繋がる可能性が高かったため優先しました。アップデートの仕方は、上げたいライブラリを最新バージョンに書き換えて、poetry update ライブラリ名で、一個ずつ手動で上げていきました。その後に下記を確認しました。テストが全てpassすることwarningsが出ていないことリリースノートに記載された破壊的な変更点に影響ありそうなコードがないこと5. その他のライブラリのバージョンアップ4と同様の手順で全てのライブラリのバージョンを上げていきます。pandasやnumpyのアップデートに特に苦労したので、今後は高頻度でアップデートをしていきたいと思いました。6. poetry update最後に、依存関係全体を最新の状態にします。poetry update継続的に実施するための取り組みライブラリアップデートは、１回実施すれば終わりではなく、継続的に実施していく必要があります。しかし、仕組みがないと継続的に実施することは難しいです。そのため、下記の取り組みを行いました。1. タスクと工数を可視化する今回ほぼ全てのライブラリアップデートを実施したので、定期的に実施する場合にどのくらいの工数が必要なのかを可視化することができました。また、poetryファイルやnpmファイルなど、ライブラリアップデートが必要なものをドキュメントにまとめることで、タスクの可視化もできました。2. Dependabotの導入Dependabotを導入することで、ライブラリアップデートのタスクの一部を自動化することができました。以下が自動化したタスクです。ライブラリの脆弱性検知の自動化ライブラリの脆弱性アップデートPRの自動作成ライブラリの脆弱性アップデートPRがパッチバージョンだった場合にオートマージする詳細は長くなるので次の章でまとめます。Dependabotでライブラリアップデートを一部自動化しようDependabotとは？Dependabotとは、GitHubが提供しているサービスで、ライブラリアップデートを一部自動化することができます。機能は下記３つです。1. Dependabot alertsGitHubリポジトリのライブラリに脆弱性が発見された場合、アラート通知を行います2. Dependabot security updatesGitHubリポジトリのライブラリに脆弱性が発見された場合、脆弱性に対応したバージョンに修正するPRを自動作成します3. Dependabot version updatesGitHubリポジトリのライブラリが最新でない場合、最新のバージョンに修正するPRを自動作成しますzenn.dev設定方法どの機能も無料で使えますが、導入するには設定が必要です。GitHubのSettingsタブにあるCode securityで機能をオンにできます。デフォルトは全てオフになっていますが、ボタンを押すだけで簡単に設定できます。ライブラリの脆弱性アップデートPRがパッチバージョンだった場合にオートマージする私たちのチームでは、1のDependabot alertsと、2のDependabot security updatesを取り入れることにしました。3のDependabot version updatesを取り入れなかった理由は、PRが溢れて管理コストが現状より増大すると考えたからです。その代わり、ライブラリ全体のバージョンアップは定期的に手動で実施する予定です。1と2を取り入れたことで、今まで実施されていなかった脆弱性の検知を自動化することができました。また、脆弱性のバージョンアップについてはDependabotがPRを自動作成してくれます。さらに、もっと自動化できないかと思っていたところ、下記の記事を見つけました。dev.classmethod.jpこちらの記事内のコードを参考に、以下の条件を満たした場合、GitHubActionsを使ってDependabotが作成したPRをオートマージするようにしました。CIのテストが全てpassしていること。パッチバージョンの更新であること（マイナー・メジャーバージョンは対象外）。マイナーバージョンやメジャーバージョンは、Dependabotがやってくれない破壊的な変更点のコード修正を別途手動で実施する必要があるため、オートマージにするのは危険そうでした。Dependabpotを使ってライブラリアップデートを全て自動化することは現状難しそうですが、一部を自動化することは工夫次第でいろいろできそうです。最後にライブラリアップデートを進めるなかで、普段から不要なコードを削除することの重要性を改めて実感しました。参考記事zenn.devzenn.devdev.classmethod.jpgithub.comdocs.github.comdocs.github.comdocs.github.com

現場で使えるライブラリアップデートの進め方

こんにちは、ENECHANGEの石橋です。AWSのコストを管理することは、企業にとって非常に重要です。システム機能概要全体および環境別の予算を設定し、超過時にアラートをSlack通知します。設定した予算に対して月次コストレポートを作成し、Slack通知します。システムアーキテクチャ概要以下は、AWSコスト監視システムのアーキテクチャ図です:主要コンポーネントAWS Budgets:全体および環境別の予算を設定。予算超過時に通知をトリガーします。Amazon SNS:通知のハブとして機能し、アラートをAWS Chatbotに転送します。AWS Chatbot:アラートをリアルタイムでSlackチャンネルに送信します。AWS Event Bridge:月次の定期トリガーを設定し、Lambdaを起動することでレポートの自動化を実現します。AWS Lambda:月次コストレポートを処理し、AWS Cost Explorerにクエリを投げてコストの詳細を取得します。Slack:予算アラートや月次レポートの通知を一元化します。実装の詳細0. タグの設定コスト監視したいサービスの全てにServiceタグをつけてください。コスト監視したいサービスの全てにEnvironmentタグをつけてください。共通部分：Common個別部分：Production, Staging, Development 等1. AWS Budgetsの設定AWS Budgetsを使用してコストの閾値を設定します。以下はServiceタグとEnvironmentタグでフィルタリングした実装例です。AWS BudgetsのTerraformコード例 resource "aws_budgets_budget" "monthly_cost_budget_development" {  name              = "Monthly-Cost-Budget-Common"  budget_type       = "COST"  limit_amount      = "1000" # USD  limit_unit        = "USD"  time_unit         = "MONTHLY"  cost_filter {    name = "TagKeyValue"    values = [      "user:Service$your-service-name",      "user:Environment$development"    ]  }  notification {    comparison_operator = "GREATER_THAN"    threshold           = 100    threshold_type      = "PERCENTAGE"    notification_type   = "FORECASTED"    subscriber {      address = aws_sns_topic.cost_alert_topic.arn      type    = "SNS"    }  }}2. SNSとChatbotの統合SNSは予算アラートをAWS Chatbotに送信し、それをSlackに転送します。SNSのTerraformコード例resource "aws_sns_topic" "cost_alert_topic" {  name = "cost-alert-topic"}resource "aws_sns_topic_policy" "cost_alert_policy" {  arn = aws_sns_topic.cost_alert_topic.arn  policy = jsonencode({    Version = "2008-10-17",    Statement = [      {        Sid       = "AllowBudgetsToPublish",        Effect    = "Allow",        Principal = {          Service = "budgets.amazonaws.com"        },        Action    = "SNS:Publish",        Resource  = aws_sns_topic.cost_alert_topic.arn      },      {        Sid       = "DefaultPermissions",        Effect    = "Allow",        Principal = {          AWS = "*"        },        Action = [          "SNS:GetTopicAttributes",          "SNS:SetTopicAttributes",          "SNS:AddPermission",          "SNS:RemovePermission",          "SNS:DeleteTopic",          "SNS:Subscribe",          "SNS:ListSubscriptionsByTopic",          "SNS:Publish"        ],        Condition = {          StringEquals = {            "AWS:SourceOwner": data.aws_caller_identity.current.account_id          }        },        Resource  = aws_sns_topic.cost_alert_topic.arn    ]  })}3. AWS Cost Explorerへのクエリ処理月次で前月の詳細なコストデータを取得するために、Lambdaを使用してAWS Cost Explorerにクエリを投げます。Cost ExplorerクエリのLambda関数例import boto3import datetimeimport jsonimport requests# Cost Explorerクライアントce = boto3.client('ce')def lambda_handler(event, context):    today = datetime.date.today()    start_of_month = today.replace(day=1)    end_of_month = today    response = ce.get_cost_and_usage(        TimePeriod={            'Start': start_of_month.strftime('%Y-%m-%d'),            'End': end_of_month.strftime('%Y-%m-%d')        },        Granularity='MONTHLY',        Metrics=['UnblendedCost'],        Filter={            'And': [                {                    'Tags': {                        'Key': 'Service',                        'Values': 'your-service-name'                    }                },               {                   'Tags': {                       'Key': 'Environment',                       'Values': 'development'                   }               }            ]        }    )    dev_cost = float(response['ResultsByTime'][0]['Total'].get('UnblendedCost', {}).get('Amount', 0.0))4. 月次レポートの自動化月次コストレポートはEventBridgeを使用してトリガーされ、Slackに送信されます。月次トリガーのEventBridgeルールresource "aws_cloudwatch_event_rule" "monthly_trigger" {  name                = "monthly-cost-report"  schedule_expression = "cron(0 0 1 * ? *)" # 毎月1日に実行}resource "aws_cloudwatch_event_target" "lambda_target" {  rule      = aws_cloudwatch_event_rule.monthly_trigger.name  arn       = aws_lambda_function.report_lambda.arn}resource "aws_lambda_permission" "allow_cloudwatch_to_invoke_lambda" {  statement_id  = "AllowExecutionFromCloudWatch"  action        = "lambda:InvokeFunction"  function_name = aws_lambda_function.report_lambda.function_name  principal     = "events.amazonaws.com"  source_arn    = aws_cloudwatch_event_rule.monthly_trigger.arn}Slack通知のLambda関数例    url = "https://slack.com/api/chat.postMessage"    headers = {        "Authorization": f"Bearer your-slack-token",        "Content-Type": "application/json"    }    payload = {      "channel": "your-slack-channel",      "text": f"development cost: {dev_cost}"    }    response = requests.post(url, headers=headers, json=payload)    if not response.json().get("ok"):        raise Exception(f"Slack API Error: {response.json()}")今後の拡張将来的には以下の機能を追加予定です:Cost Explorerレポート:詳細なレポートを生成してエクスポート。カスタムダッシュボード:Quicksightや外部ツールと統合して高度な可視化を実現。結論AWS Budgets, SNS, Chatbot, Event Bridge, Lambda, Slackを統合したこのシステムにより、リアルタイムのコスト監視、及び月次レポートのSlack通知が可能になります。このシステムをご参考にしていただき、AWSコスト管理の最適化にお役立てください。

AWSコスト監視システムを作ってみた

ENECHANGEの Yuto Ono です。エンジニアリングマネージャーをしながら、フロントエンドの開発もしています。最近、新たなプロジェクトが立ち上がり、フロントエンド、バックエンドともにTypeScriptで開発しています。TypeScript好きの僕にはたまらない環境で、楽しく開発しています。フロントエンドは React + React Router、バックエンドは NestJS + Prisma を採用しており、フロントエンド・バックエンド間の通信には REST API を使用しています。NestJSの機能で OpenAPI 形式のファイルを出力し、ライブラリでフロントエンド側から呼び出せるAPIクライアントを作成しています。今日はそのAPIクライアントを作成するライブラリを、 OpenAPI Generator から Orval に乗り換えた話をしようと思います。OpenAPI Generator の使いにくいところJRE (Java Runtime Engine) が必要データフェッチの際に useEffect と組み合わせる必要があるSWR等のライブラリと組み合わせて使うと、キーの管理が必要になるなぜか Type Error が出るOrval に移行したら幸せになったJRE が不要にSWRのフックを自動生成してくれる。キーの手動管理も不要にType Error が出ない活発に開発されているその他のメリットさいごにOpenAPI Generator の使いにくいところ最初は、定番で、社内でも使用例のある、 OpenAPI Generator を使ってAPIクライアントを出力していました。しかし、それだと使いづらい点がいくつか出てきました。※ あくまで僕が取り組んだプロジェクトで使いづらかったという話です。OpenAPI Generator を批判する意図はありません。JRE (Java Runtime Engine) が必要OpenAPI Generator はJavaで作られているため、動かすにはJavaのランタイムが必要になります。せっかくフルTypeScript環境で開発しているのに、 OpenAPI Generator を動かすためだけに、Javaのランタイムをインストールする必要が出てきて、環境構築の手間が増えてしまいます。データフェッチの際に useEffect と組み合わせる必要があるOpenAPI Generator はあくまでもAPIクライアントの生成に特化しているため、実際にReactのコンポーネントでデータフェッチを実装しようとすると、下記のように、useEffect と組み合わせる必要があります。必要以上に複雑で、コードが読みにくいです。const [userProfile, setUserProfile] = useState();useEffect(() => {  const loadUserProfile = async () => {    const userProfile = await apiInstance.getUserProfile();    setUserProfile(userProfile);  };  loadUserProfile();}, []);ちなみに筆者は 最近遭遇した useEffect のアンチパターンを紹介 【React】 でも書いたように、不要な useEffect は避けたいと思う派です。データフェッチの useEffect はコードが読みづらくなるため、できれば避けたいです。なお、React19で利用可能になったサーバコンポーネントを使用すると、普通に await が使えるため、かなりシンプルな記述にできます。とはいえ今回はSSRしない構成なので、残念ながらサーバコンポーネントは使えません。SWR等のライブラリと組み合わせて使うと、キーの管理が必要になるSWR や TanStack Query 等のデータフェッチ系のライブラリを使用すれば、 useEffect の使用は避けられます。const { data, error, isLoading } = useSWR("GET /user-profile", () => apiInstance.getUserProfile());しかし別の問題が発生します。キャッシュキー（上記の "GET /user-profile" に相当）を、自分で書く必要があります。ということは、ヒューマンエラーが発生する可能性があります。コピペしてキーを変え忘れて重複してしまったなんてことはあるあるです。なぜか Type Error が出るOpenAPI Generator が出力したファイルがなぜか型エラーを出していました。時間の関係で詳しい原因や解決方法は判明していませんが、調べたら同じ症状の方がいそうだったので、 TypeScript 向けジェネレータの不具合なのかもしれません。実行時は問題なく動くので、ひとまず、自動生成されたファイルの先頭に // @ts-nocheck コメントを挿入するスクリプトを書いて乗り切りました。とはいえ余計なスクリプトを書いている感があって気持ち悪かったです。ここに挙げた以外にも不満・不安な点はあるのですが、キリがないのでこの辺にしておきます。憶測ですが、Java製のライブラリのため、TypeScriptと相性が良くないのかもしれません。Javaのプロジェクトだと使いやすい可能性もあることは補足しておきます。Orval に移行したら幸せになったそこで、上記の問題を解決すべく調査したら、 Orval というライブラリを見つけました。良さそうだったので、さっそく導入したところ、上記の問題がすべて解決されて幸せになりました。JRE が不要にOrval は TypeScript で作られているので、Node.js の環境があれば動かすことができます。これでJavaのランタイムをインストールする必要がなくなりました。SWRのフックを自動生成してくれる。キーの手動管理も不要にOrval ではSWRのフックを出力するよう設定することができます。これにより、キーの手動管理から解放され、ヒューマンエラーも防ぐことができます。const { data, error, isLoading } = useGetUserProfile();上記の設定をした場合も、下記の通り通常の APIクライアントも生成されるため、 OpenAPI Generator の上位互換という印象を受けました。const userProfile = await getUserProfile();他にも TanStack Query などにも対応しており、非常に便利です。Type Error が出ないOrval に乗り換えたら Type Error が出なくなったので、余計なスクリプトを削除できました！活発に開発されているいくら便利なライブラリでも更新が途絶えていると安心して使うことができません。Orvalは、直近（2024/12時点）、月1ぐらいのペースで新しいバージョンがリリースされているので、今のところ安心して使えます。その他のメリット他にも、Orval を調査する中で下記のメリットがありそうでした。しかし、まだ今はそれらのメリットを活かせていないので、今後それらのメリットが活きてくるようにしていきたいです。OpenAPI Generator と比べて実行速度が速いらしいという話を見かける今はまだ実行速度の差を体感できるほどの規模ではないMockの自動生成機能があるのでテストしやすい今の段階では実装を優先してフロントエンドのテストを後回しにしているので、まだ活用できていないさいごにOrvalに乗り換えてから、あらゆる面で便利になり、開発体験が爆上がりしました。あきらめずに、より良いライブラリを探したかいがありました。弊社ではOrvalの導入事例は、おそらく初めてです。年末に社内のLT大会があるので、そこでOrvalの良さを布教していこうと思います！

APIクライアントを OpenAPI Generator から Orval に移行してみた

🎅「AWS Community Builders Advent Calendar 2024」12日目の記事です🎄CTO室の岩本 (iwamot) です。現在CTO室では、AWS Organizationsによるマルチアカウント環境への移行に取り組んでいます。複数事業部の開発環境や本番環境が同じアカウントに混在していて、セキュリティにもコスト管理にも不都合だったためです。今回初めてAWS Organizationsを使ってみて、困った点が2つありました。スタンドアロンアカウントだった期間のコストデータにアクセスできなくなったクレジットカード払いから請求書払いに変えるのに時間がかかったこれらは今のところ、AWSの仕様なので受け入れるほかありません。ただ、影響を抑えるために準備できることがあります。あるんです。今回の記事では、これら仕様の影響を抑えるために準備できることをお伝えします。これから移行する方の参考になれば幸いです。1. スタンドアロンアカウントだった期間のコストデータにアクセスできなくなった作業中にスタンドアロンアカウント（組織に属していないアカウント）を組織へ移したところ、移す前には見えていたコストデータが見えなくなってしまいました。この仕様については、AWSのドキュメントに書かれています。スタンドアロンアカウントが組織に加わります。これ以降、そのアカウントは、スタンドアロンであった期間のコストと使用状況データにアクセスできなくなります。事前に読んでいなかった、ぼくのミスということですね。この仕様の影響を抑えるには、別のAWSドキュメントにある通り「移行前にエクスポートする」のが有効です。過去の請求データにアクセスする必要がある場合は、組織への加入の招待を承諾する前に、コストと使用状況のレポート (AWS Cost and Usage Report文書) を作成して、アカウントの過去の請求データを Amazon Simple Storage Service (Amazon S3) バケットにエクスポートしてください。組織への移行後にもコストデータを確認したい場合は、忘れずにエクスポートしておきましょう。2. クレジットカード払いから請求書払いに変えるのに時間がかかった次のような組織を作ったあとで、管理アカウントがクレジットカード払いになっていることに気づきました。管理アカウント（新規作成）メンバーアカウントA（請求書払いのスタンドアロンアカウントを移行）メンバーアカウントB（同上）マネジメントコンソールには請求書払いの選択肢すら表示されていません。しかし各メンバーアカウントの支払額が大きいため、どうしても請求書払いに変える必要があります。あわてて調べたところ、FAQに次の記述がありました。AWS の請求は基本的にクレジットカード決済となりますが、請求額が大きい場合はクレジットカードの与信枠を超えてしまうケースもあることから、一定条件を満たす場合には お客様より AWS 口座へ送金いただく仕組みをご用意しております。 送金にかかる手数料はお客様負担でございます。日本担当チームまでご相談ください。つまり「アカウントを作るとデフォルトでクレジットカード払いとなり、請求書払いに変えるにはAWSに相談する必要がある」ということです。すぐAWSサポートに連絡しましたが、請求書払いが認められるまでには相当の日数がかかりました。管理アカウントは新たに作ることが多いので、これからの方は「余裕を持ってAWSに相談する」ことをお勧めします。まとめ今回の記事では、AWSのマルチアカウント移行にまつわる仕様と影響軽減策をお伝えしました。仕様影響軽減策スタンドアロンアカウントだった期間のコストデータにアクセスできなくなる事前にエクスポートするクレジットカード払いから請求書払いに変えるには時間がかかる余裕を持ってAWSに相談するこれから移行する方はご注意ください。ドキュメントをよく読んで計画を立てることをお勧めします。マルチアカウント移行は大変ではありますが、セキュリティ強化やコスト管理の効率化といった大きなメリットが得られるはずです。じっくり準備を進め、効率的な運用を目指しましょう。

あとで困らない！AWSマルチアカウント移行の前に2点のチェック

CTO室の岩本 (iwamot) です。CTO室では、各事業部で開発しているアプリケーションのコンテナ化を横断的に支援しています。開始から1年半で、6割の環境がEC2からFargateに移行されました。今後も10割を目指して進めていきます。CloudNative Days Winter 2024 (CNDW2024) というイベントはご存じでしょうか。名前のとおり、クラウドネイティブ技術を広める主旨のカンファレンスです。11月28日から2日間、東京・有明の会場とオンラインとのハイブリッドで開催されました。event.cloudnativedays.jpそのCNDW2024に、ぼくは実行委員のひとりとして参加しました。応募前の想像よりずっと大変でしたが、終わってみればとても楽しい経験でした。この記事では架空の質問に答える形で、実行委員としての感想をお伝えします。次回以降の参加を考えている方の参考になれば幸いです。ただし当然ながら、実行委員を代表する意見ではありません。その点はご了承ください。なぜ応募したのか実行委員に応募した理由は4つありました。いずれも、それなりに果たせたと思っています。ITエンジニアの知り合いを増やしたいイベント運営のノウハウを身につけたいクラウドネイティブの知見を得たいテイクばかりではなくギブもしたいちなみに募集を知ったのは、実行委員会によるXのポストがきっかけでした。2024年度CloudNative Days実行委員会・新規メンバーを募集します！1/30(火)・1/31(水) 19:00-20:00に事前説明会を開催しますので、ご興味がある方はぜひ下記のフォームよりお申込ください！！https://t.co/cfTR92VlDj#CNDS2024 #CNDT2024— CloudNative Days (@cloudnativedays) 2024年1月24日   何を担当したのかぼくが担当したのは次の企画でした。コミュニティ・初心者LT懇親会OSS展示メインはコミュニティ・初心者LTで、登壇者の募集から当日の司会まで幅広く担当しました。他の企画は一部をお手伝いした形です。LTスペース懇親会のクイズ大会、盛り上がってましたOSS展示どこが大変だったのか大変だったのは、個人的な他のタスクと同時に進めなければならない点でした。準備期間中に受けようと考えていた資格試験があったのですが、キャパオーバーで断念したくらいです。ぼくのような一部企画の担当でもそうだったので、こうしたイベントを中心となってリードしている方は本当に大変なはずです。頭が下がります。印象に残ったエピソードは何かエピソードというわけではないのですが、知り合いのエンジニアやスポンサーの方に会場で多く声をかけていただいて励みになりました。この場を借りて御礼申し上げます。サイバーセキュリティクラウド社のWAFくん。お世話になっておりますこの経験を通じて得たものは何か参加して得られた最大のリターンはイベント運営のノウハウでした。実は9月にもCloud Operator Days Tokyo 2024という別のイベントに実行委員として参加したのですが、そちらの運営との共通点や違いが分かって参考になりました。ENECHANGEでもテックイベントを開催しているので、真似できるところはしたいと考えています。ENECHANGE - connpassどんなスキルが役立ったか企画を担当するなかで役立ったのは、エグザスやゴールドジムといったフィットネスクラブで若いころに経験したフロントスタッフとしての声掛けスキルかもしれません。意外と大きな声で呼びかけられることに自分で驚きました。なんでもやっておくものですね。次回も参加したいか「次回も参加します」と言いたいところですが、率直に少し迷っています。若いころに比べると体力が落ちているので、しんどかったのですよね。でも、とても楽しかったことも確かです。じっくり考えてみます。フォトパネルにサインして任務完了まとめこの記事では、CNDW2024に実行委員として参加した感想を架空の質問に答える形でお伝えしました。あくまで、ぼくの個人的な感想です。実行委員への応募が気になる方は、@cloudnativedaysをフォローしておくことをお勧めします。若いうちがいいですよ。

CloudNative Days Winter 2024に実行委員として参加しました

ENECHANGE株式会社において、全社的な技術基盤を支えている部署がCTO室です。各部署のインフラの計画・導入や情報セキュリティの教育、さらには全社的な技術戦略の策定など、多岐にわたるIT基盤の整備を担当しています。CTO室が存在することにより、各部署はプロダクト開発に専念でき、かつ組織横断で技術の最適化やナレッジの共有が進みます。縁の下の力持ちとして、会社全体の技術的な成長を後押しする役割を果たしています。今回は、CTO室に所属するVPoT兼マネージャーの岩本隆史とエンジニアの深堀哲史、常盤匠に、これまでCTO室が担ってきたプロジェクトの事例について聞きました。ハイスキルなエンジニアが集まり、全社的な技術基盤を支える――みなさんの簡単な自己紹介からお願いします。岩本：VPoTとCTO室のマネージャーをしています。2021年7月にENECHANGEに入社し、直後からCTO室のインフラエンジニア兼SREとして参画しました。その後、前任のVPoT兼CTO室のマネージャーだった方から、その役割を引き継ぎました。私はこれまでのキャリアのなかで、社会貢献度が高いとか、自分が誇りに思えるような会社で働きたいと考えて企業選びをしてきました。前職のアマゾン ウェブ サービス ジャパンを退職することを決めてからもそうした軸で会社を探していたところ、ENECHANGEを見つけました。ENECHANGEの取り組む事業というのは、エネルギーの課題という、人類の存続にも関わるくらい重要なテーマを扱っていますので、この領域で仕事をしたいと思いました。深堀：私は入社したのが2019年で、かつてはエネルギークラウド事業部のバックエンドエンジニア兼プロジェクトマネージャーとして、顧客との要件調整・折衝やプロジェクトの管理、システムの設計・実装など幅広い業務を担っていました。より技術にフォーカスした働き方をしたいと考え、2022年にCTO室へ異動し、いまはバックエンドやクラウドインフラを扱うエンジニアとして、さまざまなプロジェクトを担当しています。私も岩本さんと同じように、ENECHANGEが解決しようとしている社会課題に魅力を感じました。それに加えて、他にも会社との縁を感じたエピソードがあります。新卒でSIerに勤めていた頃、転職活動でENECHANGEと一度やりとりをしたんですよね。その際には結局転職はしなかったんですが、久しぶりにまた同じ転職サービスでENECHANGEとやりとりをする機会があり、ENECHANGE側からも「3年ぶりですね」と返事をもらいました。これは何かの縁だと思い、採用面接を受けることにしました。常盤：私は入社が2021年11月で、今年の10月からCTO室に異動しました。異動前はエネルギークラウド事業部に在籍し、バックエンドをメインとしたWebアプリケーションの開発や、顧客との折衝などを担当していました。CTO室にはハイスキルなエンジニアが集まっており、担当するプロジェクトも技術的に難易度の高いものが多いです。この部署で働くことで、エンジニアとしてより高いスキルを身に付けられると思いました。異動してからまだ間もないので、今回のインタビューではCTO室で担当したプロジェクトではなく、エネルギークラウド事業部からCTO室がどう見えていたかなどをお話しできたらと思います。Amazon ECSへの移行により運用負荷を軽減――ENECHANGEのCTO室は、全社的な技術基盤を支える役割を担っているのですよね？岩本：そうです。大きく分けると「各サービスのインフラ（サーバー、ネットワークなど）の計画・導入・運用・保守」「情報セキュリティの技術視点でのエンジニア教育」「全社的な技術戦略の策定と事業部の技術支援」「技術ブランディングおよび採用活動の補助」という4つの業務を担当しています。今回のインタビューでは、CTO室が推進したプロジェクトの事例について、いくつかお話しします。まずは、深堀さんからAmazon ECS化対応について説明してもらいます。深堀：かつてENECHANGEでは、Webサーバーを動かすためにAWS Elastic Beanstalkを使っていました。そして、それらのサーバーの新規構築やプログラミング言語・ライブラリのバージョンアップなどに伴う環境の再構築、不要になったサーバーのリタイヤメントなどの作業はすべてCTO室が行っていたんです。ただ、この当時もCTO室は人数が少なく3～4人ほどだったため、限られたメンバーだけで全アプリケーションのProductionやStaging、Development環境をすべて管理するのはかなり大変でした。また、AWS Elastic Beanstalkではデプロイの各フェーズでフックを使用できますが、フックの処理の内容はブラックボックス化されているため、障害などが起きた際にデバッグをすることが困難です。こうした課題を解決するために、全アプリケーションをコンテナ化して、Amazon ECS上で動かすことを目指したのがこのプロジェクトになります。単にAWS Elastic BeanstalkをAmazon ECSにリプレイスするだけではなく、プロダクトチームがある程度インフラの領域も管轄できるようになることを目指しました。このプロジェクトによって、使用するプログラミング言語・ライブラリのバージョンなどをDockerfileで管理できるようになったため、バージョンアップはDockerfileの修正で対応可能になります。そして、あるプロダクトの環境をAmazon ECS化した後、それをもとにしてCTO室が環境構築のためのTerraformのモジュールを用意したことでプロダクトチームが環境の立ち上げを担えるようになりました。前述のようにデプロイの処理がブラックボックス化していたという課題も、Amazon ECS化によって解消されたため運用の負担が減りました。他にも、アプリケーションのデプロイがより楽になるように各プロダクトのリポジトリにあるコードを修正していったり、コンテナやBlue/Greenデプロイメントについて学べる資料を作ってプロダクトチームに共有したりといった活動も推進しました。その結果として、CTO室の負担は大きく軽減できました。――このプロジェクト推進時、常盤さんはエネルギークラウド事業部に所属していましたが、プロダクトチームからはどう見えていましたか？常盤匠常盤：Amazon ECS化する前は、プロダクトチームはインフラを触る機会がほとんどなく、インフラ関連の作業はCTO室に依頼をするしかない状態でした。ですが、Amazon ECSの導入に加えて丁寧に資料も作ってもらえたことで、インフラについて学ぶきっかけになりました。また、プロダクトチームがよりAWSに触れられるようにIAMの権限も付与してもらいましたし、チームによってはCTO室に頼らずにTerraformのモジュールを活用すれば簡単にインフラを構築できる体制に変わりました。こうした環境や体制の変更に伴い、プロダクトチームのメンバーたちはインフラのスキルを身に付けるモチベーションが向上しました。AWSの資格を取得するとか、インフラ関連のタスクに積極的に取り組む動きが見られるようになったんです。Amazon ECS化が運用の効率化につながっただけではなく、エンジニア個々人のスキルの幅を広げる転機にもなりました。処理可能なユーザー数を30万→500万に増やすためのアーキテクチャ刷新――他の事例についてもお話しください。深堀：エネルギークラウド事業部のDRユニットが担当している、大手エネルギー事業者向けのプロダクトがあります。現在は約30万ユニークユーザーの規模なのですが、それが今後は約500万ユニークユーザーまで増えるという事業計画があります。シンプルなWebアプリケーションであれば、単純にサーバーをスケールアウトすれば対応可能だと思います。ですが、このプロダクトでは処理のなかでデータ分析を活用しています。データ量が増えた場合でも問題なく処理できるかが不透明であったため、CTO室が検証やアーキテクチャ構築の支援に入ることにしました。現在進行形でアーキテクチャを改善しています。――すでに改善できている箇所についてご説明いただけますか？深堀：対応が済んでいる箇所として、メール送信処理のアーキテクチャが挙げられます。旧アーキテクチャでは、Redisに投入されたジョブキューをPythonの非同期ジョブ用のライブラリで受け取り、コンテナを数十個ほど並列で動かしています。そして、処理した結果をAmazon SQSに放り込み、Amazon SQSからAWS Lambdaを経由してAmazon SESを呼び出してメールを送っています。しかし、このアーキテクチャでは並列度を上げるとAmazon SQSのスロットリングやRedisのOOMエラー、ネットワークのIP枯渇などの問題が発生していました。これらのボトルネックを解消するためにPythonの非同期ジョブ用のライブラリを廃止し、AWS Batchを入れて横にスケールしやすい仕組みにするとか、AWS Step Functionsを導入してワークフロー管理できるようにするといった改善をしました。これによりスループットが20倍ほどになり、データ量が増えても問題なく処理できるようになりました。また、他にも電力使用量のデータ取り込みという、大量のファイルをインプットしたうえでフォーマット変換をかけ、大量のファイルをアウトプットする月次の処理がありました。この処理ではAmazon S3にインプット用のファイルを置き、ファイル設置されたというイベントをフックしてAmazon SQS経由でAWS Lambdaを呼び出していました。AWS Lambdaはこの処理ではAmazon DynamoDBで排他制御を行っているのですが、Amazon S3のファイル転送量が膨大であるとか、排他制御のロック待ちに起因した処理の遅延が発生していました。これを、大量ファイルの処理に適しているApache Sparkを導入することでパフォーマンス改善をしました。マネージドサービスであるAmazon EMRで動かしているため、運用の負担も軽減できています。アーキテクチャ改善によりデータ量を増やしても処理時間は140分から17分へと短縮でき、処理一回あたりのインフラコストも約150ドルから約7.5ドルに削減できました。深堀哲史チャットボットの有効活用のため、OSSにもコントリビューションする――岩本さんからも事例をお願いします。岩本：生成AIと会話できる、Slackbotを導入した話をします。昨今、生成AIがとても便利になっていますので、弊社でもそうした技術を積極的に導入しています。私たちは社内のコミュニケーションのためにSlackを使っていますが、たとえばChatGPTなどの生成AI Webサービスを利用する際にいちいちSlackとブラウザを切り替えるのがまどろっこしいと私は感じていました。そこで、生成AIと会話できるようなSlackbotを導入すれば、業務効率化につながるだろうと思ったんです。そこで、ChatGPT-in-SlackというOSSを導入しましたが、不便な点もいくつかありました。このOSSではOpenAIが提供するPythonライブラリを利用しているため、他社製のAPIを呼べなかったんですね。そこで、Microsoftが提供しているAzure OpenAI ServiceのAPIエンドポイントも使えるように、私がPull Requestを出しました。GPTの新しいバージョンも使えるようにコントリビュートを続けていったんですが、そうこうしているうちにGPT以外のモデルもどんどん優秀になってきました。OSSの作者に「さまざまなモデルを呼び出せるようにライブラリを修正しませんか」とIssueを起票して質問してみたんですが、対応する予定はないというお返事をいただいたんです。ならば、自分でより使い勝手のいいライブラリに変えていこうと思い、ChatGPT-in-SlackをforkしてCollmboというOSSを作りました。ENECHANGE社内のSlackでは、私が作ったこのCollmboが動いています。このSlackbotを導入したことで、開発職のメンバーはもちろん、ビジネス職のメンバーの業務効率化にもつながっているようです。それまでGoogle Apps Scriptを書いたことのない人が、Slackbotとやりとりをしながらプログラムを組むような事例も出てきています。岩本隆史会社への貢献と技術的な研鑽の両立ができる――CTO室で働くことの魅力はどのような点にあるでしょうか？深堀：新しい技術を取り入れたり、R&D（研究開発）をしたりというプロジェクトが多いことが非常にうれしいですね。会社への貢献と自分自身のスキルアップが同時にできるのが、CTO室の仕事の大きな魅力です。常盤：あらゆる事業部から頼られることが多いので、特定の事業やプロダクトだけにとどまらず会社全体に価値を提供できることが魅力です。難易度の高い依頼が来ることも多いので、相応の技術力やコミュニケーションスキル、調整力などは必要になりますが、そうした仕事を通じてスキルアップできるのが楽しいです。岩本：私たちは主にAWSを使用しているので、AWSの知識は間違いなく増えていきます。私は今年、AWS Community Builderに選出していただいたのですが、これはENECHANGEのCTO室で活動したからこそ実現できたことだと思います。さらに、AWS以外のパブリッククラウドも使っていますし、IaCやCI/CD系のツールなどにも触れることができ、それらを用いてシステムの改善提案ができるのは非常に面白いですね。――それでは最後に、将来的にCTO室のメンバーとしてENECHANGEに参画する可能性のある方々に向けて、メッセージをお願いします。岩本：私が個人的に考えている目標は、私の後任になる方を探すことです。もちろん社内のメンバーを育ててその方に任せる可能性もありますし、これからENECHANGEへの入社を考えているハイスキルな方がいればその人にお願いする可能性もあると思います。ぜひ、積極的にチャレンジしてください。深堀：技術的なプロフェッショナルとしてトライ&エラーしながら成長していける環境です。技術力をさらに磨きたいとか、技術を活かして会社に貢献したいならばすごく向いている場所ですし、そういう方と一緒に働きたいです。常盤：私はまだまだ若輩者なのですが、他のメンバーたちはみなすごくハイスキルです。難しい技術的課題に挑戦したいとか、技術の力で事業を支えていくことに楽しみを感じる人にぜひ参画していただきたいです。ENECHANGEではCTO室はじめ各部門でエンジニアを募集しています。詳細はエンジニア採用サイトをご覧ください。engineer-recruit.enechange.co.jp

ECS化・パフォーマンス改善・チャットボット活用。全社的な技術基盤の根幹を支える、CTO室の改善事例

こんにちは、エンジニア採用担当の村上です！先日、STORESさん、マネーフォワードさん、ENECHANGEの3社から学生インターンに登壇いただき、「【Ruby】テックベンチャー3社のインターン生が語る！学生エンジニアの本音トーク」というテーマのオンラインイベントを開催しました。その中での発表が非常に素晴らしかったので、皆様にもレポートをお届けします。社会人と遜色ない高いレベルの業務に取り組み、スキルを磨かれており、またインターンとして働くことで「社会人として働く」ことに対する解像度も非常に高く持っている方ばかりで、私も非常に刺激を受けましたのでぜひ最後までご覧ください！Rubyを知らない私が STORES に惹かれた理由最初に登壇してくださったのは STORES 株式会社でインターンをされている大学院修士2年の大塚真太朗さんです。大塚さんはインターンを始めるまでRubyを使ったことがなかったとのこと。STORES との出会いのきっかけは就職活動に向けてなんとなく参加した1on1イベント。STORES はイベントのスポンサーなどもしているため、名前をなんとなく聞いたことがあり、さらに1on1ではこれまでの学習・開発の深い話で盛り上がることができたため、会社や人に対しての好感を抱き、ジョインすることを決めたそうです。最初に任されたタスクは、なんとなくしかわからない状態から始まりました。「CIとして行っている、Railsのassets:precompileが遅いSprocketsから依存しているexecjsを速くできるか調査してほしい」よく分からないながらも、「Sprocketsを起点に調査し、assets:precompileのタスクを速くする」という漠然としたイメージを持ち、取り掛かりました。ここでまずは未経験のRubyの勉強が必要になりました。Rubyの学習は、他の言語でも同じ動作のある言葉や、Ruby特有の動作、並列処理の癖など、これまで使ったことのある技術の知識をベースに違いを理解しながら進めたそうです。Rubyは日本語のドキュメントや記事が豊富、仕様もシンプルなのでスムーズにキャッチアップができたとのこと。その後内部調査をする中で、並列処理が可能な部分を発見し、ローカル環境で処理時間を40%削減することに成功。実運用に採用するのは一旦見送ったそうですが、Rubyのキャッチアップができていることを実感しました。任された課題については、execjsというRubyからJavaScriptのコードを実行するgemの、ランタイムをより速いものに差し替えることで解決できるのではないかと見立てました。速いランタイムとして案に上がったExecJS FastNodeを検討したところ、あまり改善が見込めないと判断。その原因となる並列性能の悪さを解消するためにランタイムを自作したそうです。その後レビュー等を実施し、実運用を開始。assets:precompileのタスクにかかる時間は従来から20%削減することに成功したとのこと。大塚さんはRuby未経験ながらも、公開されている豊富な情報に加え、社内の充実したサポート体制により無事業務を遂行できました。インターンを経て、個人開発では触れられない大規模で高品質なコードと、その開発体制を知ることができたと感じているそうです。マネーフォワードで学んだRuby on Railsの乗りこなし方次に登壇したのは株式会社マネーフォワードでインターンをしている大学院修士2年の髙橋光さんです。マネーフォワードとの出会いは2週間のサマーインターン。それまでは競技プログラミングの経験はあった一方で開発の経験はなく、参加できるインターンも限られる中でたまたま見つけたのがマネーフォワードさんのインターンだったそうです。髙橋さんはそのインターンで初めて、Rubyや開発に触れたとのこと。実際のインターンの業務ではマネーフォワードクラウド会計の既存機能の改修や速度改善にメインに携わっていたそう。タスクの大きさは1日で終わるものから、人を巻き込んで数ヶ月かかるものまで様々でした。こうしたインターンの業務経験での学び、気づきや心掛けたことを3つシェアしてくださいました。1.Ruby on Railsとの付き合い方開発に初めて携わって特に実感したのはコードについて、「書く力」より「読む力」の方が強く求められるということ。現状のコードを理解できれば、実装は単純だったりAIに任せられたりするため、そのように感じ、「読む力」を鍛えるため、普段からコードを批判的に読むように意識していたそう。Ruby on Rails独特のファイルの連携や、データベースへのアクセスなどでコードを追うのに苦戦したそうですが、メンターとの壁打ちも積極的に行いながら読む力を鍛えているそうです。2.タスクの進め方事前の業務のイメージは設計書を読んでプログラミングをするものだったそうですが、実際は与えられるのは課題のみ。解決の手段やタスクの進め方は自分次第で任せてもらったそうです。髙橋さんは、まず解決すべき問題を深掘りして分析し、その問題をどうしたら解決できるのかを検討、さらに今後はどのように運用できると良いのか、を順に追いながら「あとはプログラミングするだけ」になるように進めるとのこと。3.再現性を持たせる最後に、コードを読む力の強化やタスクを進めるにあたり、一番意識していたのは「再現性を持たせること」。「メンターの手を借りればできる」ではなく自立して一人前になれるように、メンターとの壁打ちを欠かさず行なっていたそうです。具体的にはまずは自分の思考をアウトプット、そこにメンターからのフィードバックをもらうことでメンターの思考フレームを身につけられるように話し合いを行なっているとのことでした。この発表から、社員を巻き込みながらインプット・アウトプットを精度高く回している髙橋さんの学びの姿勢に感銘を受けました。私のENECHANGEでのインターンシップと今後最後に登壇したのはENECHANGE株式会社 インターン生で大学2年の山田直生さん。山田さんは小学生の時からプログラミングをはじめ、Rubyにも触れていたそう。高校生の時には「中高生国際Rubyプログラミングコンテスト」で最優秀賞を受賞。大学生になってからはいくつかの企業でインターンを経験した後、現在はENECHANGEでインターンをしています。山田さんが「中高生国際Rubyプログラミングコンテスト」で最優秀賞を受賞した話については、下記インタビュー記事で詳細を語られていますのでぜひご覧ください。note.com初めに、インターンシップはいくつかの方法で探しているとのこと。技術カンファレンスやプログラミングコンテストのスポンサーを探すWebサイト 魔法のスプレッドシート他の学生のSNSで情報収集更新がきちんとされている技術ブログENECHANGEのインターンも、RubyKaigiのスポンサー一覧から見つけて応募してくださったそうです。インターンの業務としては、大手クライアント向けに提供しているEV充電アプリのバックエンド開発を担当されています。実際の案件のタスクをもらい、メンターと一緒に仕様の詳細を決めたのち、実装をしていきます。具体的なタスクとしてこれまでに取り組んだのは3つ。1.Good Jobのダッシュボードの導入Good Jobという非同期処理を行うために利用するgemについて、利用状況を可視化ができておらず状況が把握しづらかったため、ダッシュボードを導入し、Good Jobの実行状況をリアルタイムで見られるようにしたそうです。2.FCMのpush通知における500エラーのリトライスマートフォンにプッシュ通知を送信するためのサービスであるFCM（Firebase Cloud Messaging）において、時折リクエストで500エラーを返却することがあり、プッシュ通知が失敗してしまうことが課題でした。その解決に向けて、通知の際に500エラーが返却されたデバイス情報を格納しておき、時間をおいて再度エラーが起きたデバイスに向けて処理を行うようにしました。3.分間バッチにログを仕込んでCloudWatchで調査EV充電器が使用可能かどうかのステータスを毎分更新するバッチについて、1分以内に処理が終わらないケースがあるため、どの処理に時間がかかっているのかを調査したいという課題がありました。それに対してバッチ内で処理時間を計測し、その内訳をログ出力することで、バッチ処理のボトルネックを調査できるようにしました。インターンでこのような業務に取り組む中で実務経験を積むことができ、技術的な新しいチャレンジもできるのがよかったとのことです。またENECHANGEでは社内の技術勉強会（Tech Talk）にも参加でき、これまで触れたことのない知識のインプットや、他の事業部の取り組みも知ることができて学びが多いと感じているそう。今後もカンファレンスや勉強会への参加・登壇や、技術書でのインプット、ハッカソンやプログラミングコンテストへの挑戦などで技術力を深めていきたいとのことです。発表資料はこちらで公開してくださっていますのでぜひご覧ください。本イベントを主催したENECHANGE株式会社では新卒エンジニアや長期インターン生を募集しています。興味のある方は下記もご覧ください！newgrads.enechange.co.jp

テックベンチャー3社のインターン生が語る！学生エンジニアの本音とは【イベントレポート】

日本にはAWS Community Builderが足りていないので、目指すなら今がお勧めです。AWS Community Builderに選ばれると、AWSのクレジットやグッズがもらえたり、新サービスや新機能の情報が早く得られたりするなど、さまざまなメリットがあります。背景筆者の岩本は、10月12日に開催されたJAWS FESTA 2024 in 広島に参加しました。日本のAWSユーザーグループ (JAWS-UG) が主催した、全国規模の交流イベントです。そのイベントで「日本にはAWS Community Builderが足りていない」ことを知りました。AWSの沼口さんのセッションで、そのような話があったのです。実にもったいない。岩本自身、今年からAWS Community Builderとして活動しており、さまざまなメリットを感じています。ぜひ多くの方に目指していただきたく、この記事を書きました。107人も足りない沼口さんによると、AWS Community Builderの数は世界で2,244名、うち117名が日本にいるそうです。一方で、適正な人数は世界の10%、つまり224名と考えているとのことでした。224名が適正で、実数が117名なので、107名も足りないことになります。豪華グッズこちらは、イベントから帰宅したら届いていたグッズの写真です。拡張パック付きのAWS BuilderCards、re:Invent 2023の詰め合わせバッグなどが含まれています。AWS Community Builderに選ばれたおかげで、このようなグッズがもらえるようになりました。今回より前にも、いろいろ頂いています。AWSクレジットも、具体値は明かしませんが、相当な額を頂きました。結論このように、AWS Community Builderにはさまざまなメリットがあるので、足りていないうちに目指すことをお勧めします。次回、2025年1月の申請サイクルに備えて、今のうちにウェイティングリストに登録しておきましょう。下記のページから登録できます。aws.amazon.com

日本にはAWS Community Builderが足りていない

こんにちは。エンジニア採用担当の村上です！先日、新しい技術の習得と活用を促進するために始まった社内イベント「I/O Day」のアウトプットの場としてオンラインLT大会が開催されましたのでレポートをお届けします。I/O Dayの起案者岩本さんへ、起案の背景や想いをお伺いしたインタビューも下記からご覧ください！tech.enechange.co.jp開催背景・概要ENECHANGEでは3ヶ月に一度の1日間、すぐに業務に役立てるのは難しいが、興味のある新しい技術などをインプットできる日を設ける「I/O Day」を開催しています。I/O Dayの取得にはアウトプットの提出も求められます。これまではブログの執筆等でアウトプットをしていましたが、今回は初めての試みとしてLT大会を開催しました。今回は6名のエンジニアが登壇し、LTをしてくれました。当日はエンジニアでないメンバーも含む常時40名以上が参加し、非常に盛り上がりました！エネルギークラウド事業部：杉田さん「ECS Scheduled Taskについて調べてみた」最初に登壇されたのは杉田さん。携わっているプロジェクトにおいて、現状のインフラ構成では全タスクがリソースを共有しており、パフォーマンスに影響を与える可能性があることを発見し、これを解消できないかと思い、ECS Scheduled Taskについて調べたそうです。他タスクの影響を受けず、定期バッチ処理に向いていることがわかり、実業務にも活用できそうとのこと。質疑応答ではI/O Dayでの感想を質問されていましたが、今回しっかりインプットの時間を取ることが出来て非常に良かったと感じたそうです！エネルギークラウド事業部：常盤さん「AWS Step Functions ゼロから入門」2人目に登壇した常盤さんは最近ETLパイプラインやバッチ処理に関わることが多く、データ周りへの興味が出てきたため、実際の業務に活かせるかどうか、ユースケースを調査したそうです。内容の詳細は記事としても公開されていますのでぜひご覧ください！zenn.dev別の事業部でもAWS Step Functionsを検討したことがあったり、主催者の岩本さんも実際に使ったことがあるとのことで、LT後の議論も盛り上がりました。岩本さんのAWS Step Functionsの活用事例は記事になっていますので下記もご覧ください。tech.enechange.co.jpEV充電サービス事業部：佐々木さん「AWS Security Hub で検出されたリスクに対応した結果」佐々木さんは、I/O Dayではなく業務の中での取り組みですが、その結果をシェアしたいとのことでLTに参加してくださいました。「AWS Security Hub」はAWS環境全体のセキュリティ状況を可視化・管理できるサービスです。AWS Security Hubから、頻繁にアラートが飛んできていたため、今回はその中から重要度の高いリスクをピックアップして対応してくださったそうです。セキュリティグループやコンピューティング、セキュリティ関連サービスの利用に関するリスクが検出されたため、対応ができるものは対応し、難しいものは抑制することで処理したとのこと。これで頻繁なアラートが飛んでくることはなくなる、と思っていたのですが...この対応でセキュリティモニタリングを強化した結果、潜在的なリスクが顕在化し、これまでの何倍もの数のリスクが検出されるようになったそうです。一見ネガティブに見えますが、進歩ですね。見えているリスクに対応したことで潜在化していた奥深いリスクにも気づくことができてよかったと感じられています。すぐに全てに対応することは難しいですが、継続的に取り組みながらセキュアで信頼できるサービスにしていきたい、ということで非常に頼もしく感じました！CTO室：岩本さん「DockerのマルチプラットフォームイメージをGitHub Actionsでビルドして公開する際に、参考にしたドキュメントと便利だったツール」岩本さんは今回、リクエストに対応するためマルチプラットフォームイメージ2種を公開したそうです。有料のツールもありますが、今回は無料の範囲内でできる方法を採用したとのこと。実際にLTで使用したスライドを公開いただいていますので具体的な内容はこちらからぜひご覧ください！LT後にはこうした参考ドキュメントやツールなどの情報収集の仕方について質問がありました。岩本さんは、サイボウズさんの生産性向上チームのZennをよく見ているそうです。サイボウズ 生産性向上チーム 💪 | Zennエネルギークラウド事業部：清水さん「AnimaでFigmaからReactコンポーネントを自動生成してみた」Figma等のデザインツールからReact、Vue、HTML/CSSのコードを自動生成してくれる「Anima」というツールを利用しての学びや気づきをシェアしてくださいました。AnimaではAIによるコード生成や動作のコード化、レスポンシブデザインの実現などが可能です。Animaでのコード自動生成は3ステップで可能です。Figmaでデザインを作成PluginでAnimaを追加デザインを選択してコードを生成実際の画面を写してデモをしてくださいましたが、とてもスムーズにコンポーネントが生成されて驚きました！実際に使ってみて、想像以上に実用的なコードが出力でき、またオプションも豊富なのでニーズに柔軟に対応できそうとのこと。一方で、最適なコードを出力させるには、コンポーネントベースの設計やレイヤー構造の整理など、Animaに適したデザインを作る必要があるため、そのスキルを身につけるにはコストがかかりそうと感じられています。エネルギークラウド事業部：片田さん「Flutter Webの可能性を探ってみる」今回は、今後作るかもしれないアプリでFlutter Webを使う可能性があるため、どのくらい現実的に使えるのか調べての知見を共有いただきました。詳細は下記でアウトプットしてくださっていますのでぜひご覧ください！zenn.dev実際のアプリを動かしてみた際のデモを見せてくださいましたが、弊社でやりたいことを十分に実現するのはなかなか難しそうとのこと。しかし、活用できそうな部分もありそうで、もっと深掘りしたいと感じたそうです。今回のアウトプットイベントでは、I/O Dayをきっかけに興味が広がり、また知見が深まったことが伝わり、とても素敵でした！ENECHANGEには今回のI/O Dayのアウトプット以外にも、2週間に一度、LTなど技術共有を行う社内イベントの「TechTalk」や、Slackで技術の雑談や共有ができるチャンネルなど、エンジニア同士のコミュニケーションや技術情報の共有の場が多くあります。弊社ではエンジニアも含め事業部制をとっていますが、こうした発表の後には質疑応答や議論がされることも多く、事業部を超えて切磋琢磨していける環境があると感じます。ENECHANGEでは様々なポジションでエンジニアを募集していますので、エンジニア同士のコミュニケーションが活発な組織に興味のある方は下記もご覧ください！engineer-recruit.enechange.co.jp

初実施の「I/O DayオンラインLT大会」、その内容を大公開！

AWS CodeDeployでブルー/グリーンデプロイしているAmazon ECSサービスについて、もしネットワーク設定を変えたくなったら、AppSpecを編集したうえで、新しいデプロイメントをトリガーしましょう。この方法を知らないと、ECSサービスをわざわざ作り直すか、ネットワーク変更をあきらめるか、どちらかになってしまいます。背景CodeDeployでブルー/グリーンデプロイしているECSサービスでは、ネットワーク設定を直接的には変更できません。ECSのUpdateService APIを呼び出して変更しようとすると、下記のエラーが起こります。InvalidParameterException: Unable to update network parameters on services with a CODE_DEPLOY deployment controller. Use AWS CodeDeploy to trigger a new deployment.これは、CodeDeployで新しいデプロイメントをトリガーする必要があることを示すエラーメッセージです。この制約についてはドキュメントにも書かれています。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 Service解決策新しいデプロイメントをトリガーすべきなのは分かりましたが、具体的にどうしたらよいのでしょうか。答えは「AppSpecを編集してからトリガーする」です。編集せずにCodeDeployのCreateDeployment APIを呼んでトリガーしても、当然ながらネットワーク設定は変わりません。appspec.ymlの場合、下記のように編集します。        NetworkConfiguration:          AwsvpcConfiguration:            Subnets: ["subnet-1234abcd","subnet-5678abcd"]            SecurityGroups: ["sg-12345678"]            AssignPublicIp: "ENABLED"引用元：AppSpec File example - AWS CodeDeployECSタスクのサブネットやセキュリティグループ、また、パブリックIPアドレスを割り当てるかどうかを、AppSpecで指定するわけです。その際には、下記ドキュメントの通り Subnets、SecurityGroups、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 CodeDeployAppSpecを編集後、新しいデプロイメントをトリガーすれば、ネットワーク設定が変わります。グリーン環境のECSタスクが、指定したネットワークで起動されるはずです。デプロイメントが完了したら、AppSpecから NetworkConfiguration を削除してOKです。まとめ以上のように、CodeDeployでブルー/グリーンデプロイしているAmazon ECSサービスでも、AppSpecを編集したうえで新しいデプロイメントをトリガーすれば、ネットワーク設定が変えられます。筆者の岩本はこの方法を知らず、もう少しでECSサービスを作り直すところでした。この記事が、似たような状況にある方の参考になれば幸いです。

ブルー/グリーンなAmazon ECSサービスのネットワーク設定を変える方法

ENECHANGEの Yuto Ono です。エンジニアリングマネージャーをしながら、フロントエンドの開発もしています。2024年4月に、React 19 Beta がリリースされました。2024年9月現在、 React 19 はRC版となっており、正式リリース間近となっております。そこで、早めに React 19 の新機能をキャッチアップし、正式リリース時にスタートダッシュをきれるようにしたいと思いました。最近、実務でアンケート機能の実装をしていることもあり、このようなアンケートアプリケーションを作ってみました。React 19 の機能をふんだんに使ってみましたので、その解説を書いていこうと思います。アクションuseActionStateuseOptimisticuseフック<Context.Provider> → <Context>メタデータのサポートrefを propsとして受け取れる（forwardRefが不要に）その他の新機能・改善まとめ今回のソースコードはこちらのGitHubリポジトリに公開しています。github.comまた、こちらにデプロイしております。よかったら触ってみてください。https://yuto-ono-react-19-sample.vercel.app/また今回 React 19 の学習にあたり、React公式ブログと、uhyoさんのZenn本を参考にさせていただきました。この場をお借りして、お礼申し上げます。ja.react.devzenn.devアクションReact 19 を語るうえで欠かせないのが、「アクション」という概念です。これは、非同期処理をスマートに実装できる仕組みのようなものです。詳しい説明は、React公式ブログや、uhyoさんの解説記事をご覧ください。アクションの最も基本的な実装方法は、 useTransition に非同期関数を渡すことです（React 18 にも useTransition がありますが、非同期関数を処理する機能はないのでご注意ください）。なお、他にもアクションを扱う便利なフックがあり、例えば後述する useActionState などがあります。実際にはそちらを使ってアクションを定義することが多いでしょう。useActionStateuseActionState は、アクションの定義とstateの管理を同時にできるものです。useFormState からリネームされただけあって、公式ドキュメントを見ても、フォームとともに使うことを想定されていそうです（もちろん、フォーム以外でも使うことができます）。また、それに関連して、 form の action に、非同期アクションを指定することができるようになりました。しかも、アクションの引数に formData が渡されるため、入力された値を取得するのも簡単にできるようになりました（公式ドキュメント）。今後は、フォームが非制御コンポーネント (uncontrolled component) で良い場合は、追加のライブラリなしでも快適に実装できそうです（制御コンポーネント (controlled component) を使う場合は、今まで通り、 react-hook-form などのライブラリを導入するのが良さそうです）。実際、今回の試作アプリでも、 useActionState を使って、送信途中や、送信後の挙動などをスマートに実装することができました。useActionState 使用箇所useOptimisticuseOptimistic は楽観的更新を行うためのフックです。これを使うと、非同期アクションの完了を待たずに、UIを更新することができます。いいねボタンを押したときにレスポンスを待たずにいいねのカウントが増えるイメージです。これにより、ユーザーにアプリケーションがサクサク動く印象を与えることができます。実際、今回、フォーム送信処理のモックにわざと1秒のsleepを入れていますが、送信処理が終わるのを待たずにアンケート結果が描画されていることがわかります。useOptimistic 使用箇所（上と同じ）useフックuse はPromiseやContextなどのリソースから値を読み取るためのフックです（公式ドキュメントでは、フックではなくて React API として紹介されていますが、便宜上フックと呼びます）。ただし、今回は、Promiseを読み取るための useは使いませんでした。なぜなら、公式ブログにはプロミスをキャッシュできるサスペンス対応のライブラリまたはフレームワークで作られたプロミスを渡す必要があります。とあり、現時点では他のライブラリと組み合わせて使うことが前提となっているからです。結局、データフェッチ系は、実務でも使っている、SWR で実装しました。将来的には、レンダー中にプロミスをキャッシュしやすくする機能を提供する予定です。とあるので、近いうちに、 React だけでデータフェッチを良い感じに書けるようになるかもしれません。良い感じのキャッシュ機構が開発されるのを楽しみに待ちましょう。もう1つの、Contextを読み取るための useは、下と関係するので、そこで一緒に言及します。<Context.Provider> → <Context>今まで <Context.Provider> と書いていたものが、 <Context> と書けるようになります。いずれは <Context.Provider> が非推奨になります（公式ブログ）。ちょっとした改善ですが、読みやすくなっていいですね。それに関連して、 useContext(Context) の代わりに、 use(Context) と書けるようになりました。読みやすくなっただけでなく、柔軟さも増しているようなので、今後はContextに対しては useを優先的に使うことが推奨されます（公式ドキュメント）。<Context> 使用箇所use 使用箇所メタデータのサポート<title>、<link>、<meta> などのメタデータタグをレンダリングするのに、今までは react-helmet のようなライブラリが必要でしたが、React 19 からはメタデータタグを認識して自動的に <head> セクションに移動してくれるようになりました（公式ブログ）使用箇所refを propsとして受け取れる（forwardRefが不要に）今まで forwardRefを使って回りくどい方法で refを渡していたのが、シンプルに propsで refを受け取れるようになります（公式ブログ）。その他の新機能・改善他にも今回紹介しきれなかった新機能・改善が色々あります。ぜひ公式ブログやuhyoさんの記事を参考にしてみてください。サーバコンポーネント・サーバアクションハイドレーションエラー時の差分表示ref 用のクリーンアップ関数useDeferredValue の初期値スタイルシートのサポート非同期スクリプトのサポートリソースのプリロードサードパーティのスクリプトおよび拡張機能との互換性改善カスタム要素のサポートまとめReact 19 で登場したアクションという概念と、それを扱うための useActionState 、useOptimistic は、非同期処理を実装するうえで、非常に便利だと感じました。きっと周辺ライブラリもアクションに対応してくると思うので、そのへんもウォッチしていきたいなと思いました。それ以外にも嬉しい新機能や改善が色々とあったので、19の正式リリースが楽しみです。あと、フロントエンド界隈は常に新しい技術や概念が出続けるので、勉強を続けることが大事だと思いました。ぜひ皆さんも常に新しい情報をキャッチアップし続けていきましょう！

React 19 RC で、アンケート画面を作ってみた

すべての情報処理技術者試験に合格するには「体力」が、すべてのAWS認定資格を取得するには「お金」が、それぞれ最大の鍵です。鍵が分かれば、効率よくダブル全冠が狙えます。相手を知らずに戦うのは非効率です。ダブル全冠が達成できれば、エンジニアとしての市場価値が高まります。レアだからです。現時点の達成者は多くて数百人でしょう。背景筆者の岩本は2021年にIPA全冠を、また本日、AWS全冠を達成しました。その経験で気づいた戦い方をお伝えし、参考になればと思っています。IPA全冠：若いうちに省エネして狙うIPA全冠の鍵は体力です。高度試験は9:30から16:30まで論述式の問題では2時間で3,000字ほど筆記が必要なので、以下の戦略が有効です。若いうちに受ける（今が人生でいちばん若い）午前I試験は免除を狙う試験会場の近くに前泊する疲れにくい筆記用具を使う（マークシート用鉛筆とデルガードがおすすめ）とくに高度試験こそ若いうちの受験をおすすめします。年に一度しかない機会を逃せば、それだけで1年の損です。ちなみにぼくは、体力が落ちてきたので、もう受けたくありません。IPA全冠を達成していちばんうれしかったのは「もう受けなくて済むこと」でした。AWS全冠：勤務先の福利厚生で狙うAWS全冠の鍵はお金です。試験によっては受験料が40,000円（情報処理技術者試験は7,500円）3年ごとに更新が必要（情報処理技術者試験は更新不要）なので、以下の戦略が有効です。勤務先に受験料補助や資格手当があれば遠慮なく使うそのような仕組みがなければ提案する提案してもダメなら転職するたとえば、ENECHANGEには受験料補助の制度があります。IPAでもAWSでも、合否にかかわらず、全額を補助してくれるありがたい制度です。この制度、ぼくが提案したものでした（「ENECHANGE における AWS 認定受験料補助制度の創設」）。社員の成長を願っている企業であれば、きっと検討してくれるはずです。AWS無冠だったぼくは、受験料負担ゼロで、AWS全冠が達成できました。結論ダブル全冠を効率的に狙うには、以下の戦略が有効です。IPA全冠：若いうちに省エネして狙うAWS全冠：勤務先の福利厚生で狙うエンジニアとしての市場価値を高め、キャリアの選択肢を増やすために、ぜひ次の情報処理技術者試験に申し込みましょう。

IPAとAWSのダブル全冠、鍵は体力とお金

概要CloudTrailはCloudWatchLogsと統合できるため、CloudWatchを利用して改ざんや不正アクセスに関連する疑わしいイベントを検出できます。検知条件の策定セキュリティと運用の観点から合理的かつ包括的なアプローチを取るためにターゲットは下記としました。CloudTrailAWS全体の監査基盤であり、これ自体の設定変更を監視することは、AWSリソース全体の監視に直結します。S3重要なデータの保管場所であり、機密データの改ざんやアクセス制御の変更を監視することでデータの保護を強化できます。闇雲に指定しても意味ないので、下記要件を1つでも満たすものを対象とした。機密性の高いデータを含むコンプライアンス要件があるビジネスクリティカルなデータを含むアプリケーションの設定ファイル、バックアップデータ、重要なレポートなど外部公開されている（存在しない認識）Lambda全Functionを対象としました。サーバーレスアーキテクチャの中心として、アプリケーションロジックを保護するための監視が重要です。CloudTrailCloudTrailに適用する検知条件1. CloudTrailの無効化（StopLogging / DeleteTrail）説明: 攻撃者がAWSアカウントに不正アクセスした場合、最初に監査ログを無効化しようとする可能性があります。これにより、後続の不正アクション（例: リソース削除、データアクセスなど）が監視されなくなります。リスク: StopLogging や DeleteTrail APIが実行されると、CloudTrailはログ記録を停止します。不正アクセスや改ざんの追跡が困難になります。対策: これらのイベントをCloudWatch Logsで監視し、検知した際にすぐに対応できるようにする。2. ログの保存先S3バケット変更（UpdateTrail）説明: CloudTrailのログ保存先バケットが変更されると、誤って設定されたバケットに保存され、不正アクセスの痕跡が削除・改ざんされる可能性があります。リスク: 不正なバケットポリシーの場合、攻撃者はログを削除または改ざんする可能性があります。対策: UpdateTrail イベントを監視し、保存先バケットの変更を検知した場合にアラートを発生させる。3. CloudTrailのロギング無効化（StopLogging）説明: StopLogging APIで特定のCloudTrailがログ記録を停止される可能性があります。これは、悪意あるユーザーが操作の痕跡を隠すために行われることがあります。リスク: ログ記録が停止されると、セキュリティ監査に必要なデータが失われ、不正アクセスが検出できなくなります。対策: StopLogging イベントを監視し、すぐにCloudTrailの再開や調査を実施する。S3S3に適用する検知条件説明は省略1. オブジェクト削除 (DeleteObject, DeleteObjects)2. オブジェクト変更 (PutObject, CopyObject)3. バケットポリシーや設定の変更 (PutBucketPolicy, PutBucketAcl, PutBucketVersioning)4. バケット削除 (DeleteBucket)LambdaLambda関数に適用する検知条件1. Lambda関数の無効化や削除（DeleteFunction / UpdateFunctionConfiguration）説明: 攻撃者が不正アクセスを行った場合、Lambda関数を無効化または削除することで、ビジネスロジックを停止させる可能性があります。リスク: DeleteFunction や UpdateFunctionConfiguration APIが実行されると、Lambda関数が無効化され、重要なビジネスロジックや処理が停止する恐れがあります。対策: これらのAPI呼び出しをCloudWatch Logsで監視し、検知した際にアラートを発生させます。2. Lambda関数の設定変更（UpdateFunctionCode / UpdateFunctionConfiguration）説明: Lambda関数のコードや設定が変更されると、不正なコードが実行され、機密データが漏洩する可能性があります。リスク: 関数のコードが改ざんされることで、悪意のある動作が実行されたり、設定変更によってセキュリティポリシーが緩和される可能性があります。対策: UpdateFunctionCode や UpdateFunctionConfiguration イベントを監視し、関数コードや設定変更が発生した場合に通知を行います。3. Lambda関数の呼び出し（InvokeFunction）説明: Lambda関数が不正に呼び出されることで、機密データの流出や不正な処理が行われる可能性があります。リスク: InvokeFunction APIが不正に呼び出され、ビジネスクリティカルなデータにアクセスされたり、不正な処理が実行される可能性があります。対策: Lambda関数の呼び出しログをCloudWatch Logsで監視し、異常な呼び出しが検知された場合にアラートを発生させます。Terraform構成chatbotとsnsはModuleにしています。cloudtrail├── cloudtrail.tf├── cloudwatch_log.tf├── cloudwatch_metric_log.tf├── iam_role.tf├── locals.tf├── main.tf└── module.tf1 directory, 7 files設定例locals {  important_s3_buckets = [    "arn:aws:s3:::xxxxxxxx/",    "arn:aws:s3:::xxxxxxxx/",    "arn:aws:s3:::xxxxxxxx/",    "arn:aws:s3:::xxxxxxxx/",  ]}# CloudTrailがCloudWatchLogsにログを書き込むためのIAMロールresource "aws_iam_role" "cloudtrail_cloudwatch_role" {  name = "cloudtrail-cloudwatch-logs-role"  assume_role_policy = jsonencode({    Version = "2012-10-17",    Statement = [      {        Effect = "Allow",        Principal = {          Service = "cloudtrail.amazonaws.com"        },        Action = "sts:AssumeRole"      }    ]  })}# CloudTrailがCloudWatchLogsにログを送信するためのポリシーresource "aws_iam_role_policy" "cloudtrail_cloudwatch_policy" {  role = aws_iam_role.cloudtrail_cloudwatch_role.id  policy = jsonencode({    Version = "2012-10-17",    Statement = [      {        Effect = "Allow",        Action = [          "logs:CreateLogGroup",          "logs:CreateLogStream",          "logs:PutLogEvents"        ],        Resource = "*"      }    ]  })}resource "aws_cloudwatch_log_group" "cloudtrail_s3_log_group" {  name              = "/aws/cloudtrail/cloud-trail-s3-data-events"  retention_in_days = 365}# s3の設定変更やログの停止イベントの監視resource "aws_cloudwatch_log_metric_filter" "cloudtrail_s3_change" {  name           = "S3ChangeFilter"  log_group_name = aws_cloudwatch_log_group.cloudtrail_s3_log_group.name  pattern        = "{ ($.eventName = DeleteObject) || ($.eventName = DeleteBucket) }"  metric_transformation {    name      = "S3ChangeEvents"    namespace = "S3Metrics"    value     = "1"  }}resource "aws_cloudwatch_metric_alarm" "cloudtrail_s3_change_alarm" {  alarm_name          = "CloudTrail-S3-ChangeAlarm"  comparison_operator = "GreaterThanOrEqualToThreshold"  evaluation_periods  = "1"  metric_name         = aws_cloudwatch_log_metric_filter.cloudtrail_s3_change.metric_transformation[0].name  namespace           = aws_cloudwatch_log_metric_filter.cloudtrail_s3_change.metric_transformation[0].namespace  period              = "300"  statistic           = "Sum"  alarm_actions = [    module.aws_chatbot_slack.sns_topic_arn  ]  ok_actions = [    module.aws_chatbot_slack.sns_topic_arn  ]}resource "aws_cloudtrail" "s3_data_events" {  name                          = "cloud-trail-s3-data-events"  s3_bucket_name                = <s3bucket-name>  s3_key_prefix                 = "CloudTrail-S3/" # S3用のフォルダ  is_multi_region_trail         = true  enable_log_file_validation    = true  include_global_service_events = true // グローバルサービスの管理イベント  # CloudWatchLogs設定  cloud_watch_logs_group_arn = "${aws_cloudwatch_log_group.cloudtrail_s3_log_group.arn}:*"  cloud_watch_logs_role_arn  = aws_iam_role.cloudtrail_cloudwatch_role.arn  event_selector {    read_write_type           = "All"    include_management_events = true // 管理イベント    data_resource {      type   = "AWS::S3::Object"      values = local.important_s3_buckets    }  }}module "aws_chatbot_slack" {  source             = "git@github.com:xxxxxx/terraform-modules.git//chatbot-slack?ref=x.x.x"  configuration_name = "cloudtrail-change-chatbot-configuration"  slack_channel_id   = "xxxxxxx"  slack_team_id      = "xxxxxxx" // #slack channel  sns_topic_name     = "custom-cloudtrail-change-notifications"  logging_level      = "ERROR"  iam_role_name      = "cloudtrail-change"}

CloudTrailとCloudWatchLogsの統合

こんにちは。人事室の村上です。先日弊社オフィスにて「今さら聞けない！オフィス・開発でのAI活用」をテーマにイベントが開催されました！主催は「うら原アジャイルコミュニティ」で、弊社は共催として参加しました。オフライン・オンラインの同時開催で、それぞれ10名以上の方にご参加いただき、当日も盛り上がっていましたので本記事ではレポートをお届けしたいと思います。概要今回のテーマは「オフィス・開発でのAI活用」です。登壇者3名がそれぞれ下記のテーマで発表しました。谷口 崇：生成AIとその活用岩本 隆史：RAGもファインチューニングも使わない 素朴なAIチャットボットを職場に導入した結果小野 優人：GitHub Copilotの活用方法①谷口 崇：生成AIとその活用最初に登壇されたのは谷口さん。現在は株式会社バックテックに所属され、ReactでのSPA開発をメインに携わっていらっしゃいます。今回は生成AIの成り立ちや特徴、そこから考える効果的な使い方と利用時の注意点をお話しくださいました。谷口さんは普段開発業務や新しい言語の学習、ドキュメント作成やブレインストーミングなど日常の様々なシーンで生成AIを活用されています。生成AIの活用の際のコツとして以下が挙げられました。事前知識を教えておく余計な情報は与えないステップバイステップで答えを引き出していく会話を重ねると発言を忘れていくので短く簡潔に答えを引き出すAIは非常に便利で使い方に配慮することで精度高く利用できますが、ありもしない情報を真実のように告げることもあるそうです。生成AIはあくまでツールとして、検証できる範囲で使いましょうとのこと。谷口さんはAIを壁打ち相手やアシスタントとして使っているそうです。筆者も仕事でChatGPTを利用することがありますが、思うように答えが返ってこなかったり、画像生成の結果がとんでもないことになったりします。プロンプトの作り方が難しいと感じていたので、今回学んだコツを試してみようと思います！②岩本 隆史 (iwamot)：RAGもファインチューニングも使わない 素朴なAIチャットボットを職場に導入した結果次の登壇者は岩本さん。岩本さんは当社ENECHANGEのCTO室でVPoTとして活躍されていらっしゃいます。ENECHANGEではSlackでAIチャットボットと会話ができるのですが、その仕組みを作ってくださったのが岩本さんです。今回は、岩本さんがAIチャットボットを導入した結果や、導入の際のコツを話してくださいました！ENECHANGEは業務効率の向上を目指し、ChatGPTやGitHub Copilotを希望する全従業員・エンジニアに導入しました。その後、全社的に利用している「Slack」というコミュニケーションツールにもAIチャットボットを導入しました。AIチャットボットは特にファインチューニングやRAGは行わず素のGPT-4モデルで導入しましたが、各AIツールの併用により、5ヶ月で業務効率が平均44%改善されたとのこと。SlackでAIチャットボットに質問できるチャンネルは毎日動いており、今では欠かせない存在となっています。この利用率の高さの背景には「最新モデルへのスピーディーなアップデート」があると推察しているそうです。AIの技術は日々向上し、高性能かつ高速なモデルが次々と出ます。そこでモデルの切り替えやすさを重視しChatGPT-in-Slackという環境変数の変更のみでモデルの切り替えができるOSSを利用して運用していました。しかし最近、Claude 3.5 Sonnetというモデルが出てきたためそちらも活用したいと思ったところ、上記OSSではGPTモデルしか導入できないという課題が出てきました。そこでOSSをforkしてCollmboを開発。Sonnet Botの導入に成功しました。筆者はSlackでSonnet Botが利用可能であることを恥ずかしながら初めて知りましたのでさっそく使ってみました！GPTモデルとの違いなどまだわからないことばかりですが、色々触って勉強してみたいと思います。③小野 優人：GitHub Copilotの活用方法最後に登壇されたのは小野さん。小野さんはENECHANGE株式会社でフロントエンドをメインに開発に携わられ、エンジニアリングマネージャーとしても活躍されています。小野さんは開発でGitHub Copilotを活用しているそうです。ENECHANGEでは、GitHub Copilotを希望する全エンジニアに提供しています。具体的な活用方法5つをデモ動画とともに教えていただきました。※なお、下記の活用方法はVSCodeでの使用を前提としています。他のエディターをお使いの方は適宜使用方法をお調べいただければと思います。コード補完：特に何も意識しなくても、コードを自動で補完してくれるのがとても便利です。関連ファイルをタブで開いておいたり、先にコメントを入れておくと精度がより高まるそうです。Copilot Chatで質問する：チャットで聞きたいことをすぐに聞けます。「エディタでチャットを開く」を使うと、チャットの画面が広くなり、エディタのタブとして残るので後で見返すときにも便利でオススメです。テストを書いてもらう：Copilot Chatの「コードの単体テストを追加する」というメニューから一瞬でテストを作ってもらえます。 /tests コマンドでも同様のことができます。Inline Chat in Editor：エディター内で「Command + I 」というショートカットでインラインチャットを開くことができます。そこで例えば「〇〇な関数を追加して」と指示すると、指示の意図や周囲のコードを汲み取って、関数を一瞬で書いてくれます。Inline Chat in Terminal：インラインチャットはターミナルでも使えます。コマンドを忘れてしまった時などに質問すると、コマンドを提案してくれるのでとても便利です。筆者はエンジニアではないので、開発実務に関して詳しくはありませんが、コードの記述やテストの作成など本当に一瞬の出来事だったので「すごい技術だな...」と思いました。生産性が非常に高まる機能なのだろうと感じましたのでエンジニアの皆さんぜひ使ってみてくださいね。おまけ発表終了後にはオフライン参加の皆さんでいろいろな話をして盛り上がりました。オンラインでのイベントも増えていますが、こうした交流が現地参加の醍醐味だと感じました。ENECHANGEでは定期的にイベントを開催しています。オンラインのものがメインですが、オフラインイベントも企画できればと思いましたので、最新情報はこちらからチェックしてください！https://enechange-meetup.connpass.com/enechange-meetup.connpass.comーーーーーーーーーーーーーーーーーーーーーーーー最後までご覧いただきありがとうございました。ENECHANGE株式会社では幅広い職種で仲間を募集しています。興味のある方はこちらから気軽にエントリーください！engineer-recruit.enechange.co.jp

「今さら聞けない！オフィス・開発でのAI活用」イベントレポート

VPoT兼CTO室マネージャーの岩本 (iwamot) です。プレイヤーとしては、おもにクラウド運用を担当しています。先日「IPアドレス制限のあるURLを死活監視したい」と同僚から相談され、Amazon Route 53ヘルスチェックによる監視を実装しました。シンプルな実装ですが、工夫した点もあるため、事例として共有します。要件監視対象は、AWSのALBやCloudFrontで特定クライアントにのみ公開しているURLIPアドレス制限のないURLはPingdomで死活監視しているが、今回は利用不可PingdomのIPアドレスをクロールして許可するのは手間だし、自動化も面倒アーキテクチャ実装した死活監視のアーキテクチャは以下の通りです。Route 53ヘルスチェックとCloudWatchが主役Route 53ヘルスチェックを設定し、ALBやCloudFrontのURLを監視するようにしました。利用は初めてですが、特に難しいところはありませんでした。名前とドメイン名を入れる程度でOKまた、CloudWatchアラームも設定し、異常が検知された（HealthCheckStatusメトリクスの値が「0」となった）場合に、SNSトピックに通知が飛ぶようにもしました。こちらも簡単で、メトリクスがus-east-1に記録される点に注意が必要な程度です。重要な、ヘルスチェック元IPアドレスの許可については、下表のように設定しました。監視対象IPアドレスの定義先許可ルールの設定先ALBマネージドプレフィックスリストセキュリティグループCloudFrontWAF IPセット（詳しくは別記事を参照）Web ACLRoute 53ヘルスチェックを選んだ理由監視対象がAWS上のワークロードのため一元的に管理できるマネージドサービスのため開発が不要マネージドプレフィックスリストが提供されているためアクセス許可が簡単料金が安い（URL1件あたり月1.5ドル程度）工夫した点監視対象は複数あるとのことだったので、社内用Terraformモジュールを作成し、横展開しやすくしました。現時点で10件のURLを監視中です。provider "aws" {  region = "us-east-1"  alias  = "us_east_1"}module "http-healthcheck" {  source = "git@github.com:enechange/terraform-modules.git//http-healthcheck?ref=x.x.x"  providers = {    aws.us_east_1 = aws.us_east_1  }  name          = "prod-example"                  # ヘルスチェック名  url           = "https://example.com/login"     # 監視対象のURL  sns_topic_arn = aws_sns_topic.in_us_east_1.arn  # 通知先SNSトピックのARN}まとめRoute 53ヘルスチェックを使うことで、IPアドレス制限ありのURLでも、手軽に安く死活監視が実現できました。また、ちょっとした工夫として、社内用Terraformモジュールを作成しました。おかげで、横展開がスムーズにできています。Route 53ヘルスチェックをまだ試したことのない方は、簡単に設定・破棄できますので、気軽に試していただくことをお勧めします。

IPアドレス制限ありのURLをRoute 53ヘルスチェックで死活監視する

Amazon S3における条件付きリクエストの活用特定の条件が満たされた場合にのみオブジェクトのアップロードや更新を許可する機能です。競合の防止やデータの整合性を確保するために使用できます。https://aws.amazon.com/jp/about-aws/whats-new/2024/08/amazon-s3-conditional-writes/GetObject、HeadObjectの条件付きリクエストIf-Match: オブジェクトのEtagと一致する場合にのみリクエストを実行If-None-Match: オブジェクトのEtagと異なる場合にのみリクエストを実行If-Modified-Since: 指定日時以降にオブジェクトが変更されている場合にリクエストを実行If-Unmodified-Since: 指定日時以降に変更されていない場合にリクエストを実行PutObjectの条件付きリクエストIf-None-Match: オブジェクトのEtagと異なる場合にのみリクエストを実行重要なのはS3自体には、すべてのリクエストで条件付き書き込みを標準化するための機能は提供されていません。つまり、S3の設定で条件付きリクエストを必須にすることはできません。標準化はクライアント側の実装や運用ポリシーで行う必要があります。PutObjectの使用方法主にIf-None-Matchを使用し、条件付きでオブジェクトの上書きを制御します。If-Matchはサポートされていないため、書き込み時にEtagを使った厳密な制御はできません。--if-none-match: 同名のオブジェクトがすでに存在する場合はアップロードが失敗します。オブジェクトの内容が一致しているかどうかは関係なく、名前（キー）が同じであれば条件に合致せず、アップロードが拒否されます。条件合致しないケース（同名キーが存在する）% aws s3api put-object --bucket hopstepjump --key test.data --body ~/docs/test.data --if-none-match "*"An error occurred (PreconditionFailed) when calling the PutObject operation: At least one of the pre-conditions you specified did not hold条件合致するケース(同名キーが存在しない)% aws s3api put-object --bucket hopstepjump --key test.data2 --body ~/docs/test.data2 --if-none-match "*"{    "ETag": "\"*******************************\"",    "ServerSideEncryption": "AES256"}GetObjectの条件付きリクエストIf-MatchやIf-None-Matchを使用して、Etagの一致を基にオブジェクトの取得条件を設定できます。読み取りに対してEtagによる整合性のチェックが可能です。If-MatchでEtagによる整合性をチェックするケースEtagの確認% aws s3api head-object --bucket hopstepjump --key test.data --query ETag --output text"*******************************"得たEtagを指定した条件合致するケース% aws s3api get-object --bucket hopstepjump --key test.data ~/docs/test.data --if-match "*******************************"{    "AcceptRanges": "bytes",    "LastModified": "2024-09-03T05:15:22+00:00",    "ContentLength": 8888,    "ETag": "\"*******************************\"",    "ContentType": "binary/octet-stream",    "ServerSideEncryption": "AES256",    "Metadata": {}}Etagを指定した条件合致しないケース% aws s3api get-object --bucket hopstepjump --key test.data ~/docs/test.data --if-match "*******************************"An error occurred (PreconditionFailed) when calling the GetObject operation: At least one of the pre-conditions you specified did not holdterraform.tfstateについてterraformのtfstateをDynamoDBによってロックしなくてもこの条件付き上書き機能で運用できるかも？と思いましたが、そもそもPutActionはEtagを使った制御ができませんでした。

Amazon S3 が条件付き書き込みのサポートを開始

結論サービスがIdpと連携していたとしてもALBが認証プロバイダーと連携してトークンの検証を行っていない場合、ALBeast脆弱性の影響はありません。概要https://www.miggo.io/resources/uncovering-auth-vulnerability-in-aws-alb-albeast攻撃者は正規のトークンを模倣した不正に署名されたトークンを生成し、本脆弱性を悪用すると、ALBがこの不正トークンを正しく検証せずに受け入れてしまう。その結果、Idpとの連携システムであっても発行した正規のトークンがなくても、攻撃者は偽のトークンで認証を通過できる可能性があるため、アクセス制御が回避される恐れがあります。対策AWSはALBにおける認証機能を更新済付録トークンを偽装されて接続されたとしてもアプリケーション内でもBasic認証やOAuth2.0などの認証を導入していれば悪意のある接続は防げていたそもそもALBで署名を検証できていなかったというのは耳を疑うような欠陥なので、利用料金の一部を返納しろというコメントがサポートに出てるような気もしますね...

ALB脆弱性の影響と対策

VPoTの岩本 (iwamot) です。8月24日から25日にかけて、AWSタイトルホルダーやAWS内の方が登壇しつづける24時間オンラインイベント「JAWS PANKRATION 2024」が開催されました。jawspankration2024.jaws-ug.jpぼくは24日の23:20 (JST) から「Cost-Effective SLO Error Budget Monitoring with Athena and CloudWatch」のタイトルで登壇しました。発表した内容については、スライドや、後日公開予定のアーカイブ動画をご覧いただければ幸いです。今回の記事では、登壇によって得られたものを記してみます。どなたかの登壇意欲に火をつけられたら、と願っています。豪華なSwagまずは物理的なものから。登壇者は豪華なSwagがいただけました。jawspankration2024.jaws-ug.jp特にデジタル名刺のプレーリーカードは、オフラインイベントでのコミュニケーションで活躍してくれそうで、ありがたい限りです。どこかでぼくを見かけたら、実物をお見せしますので、ぜひお声がけください。世界的イベントで話した実績ここからは精神的に得られたものです。まず、世界的イベントで話す実績が解除できました。https://jawspankration2024.jaws-ug.jp/ja/news/z9rhwkzd4/ よりこのようなイベントでは英語で話さなければならないことが多く、英語が苦手なぼくは応募を控えるのが常でした。しかし、JAWS PANKRATION 2024では、同時翻訳が実装されており、発表者の音声をいろんな言語に訳して読むことができました。そのおかげで安心して応募でき、世界的イベントで話す実績が解除できたのです。準備不足への反省といいながら、ぼくの話し方が下手すぎたせいで、実はうまく翻訳できていなかったようでした。一文を短くしてはっきり発声する、文のあとにスリープを入れる、などの注意点を守れなかったのが原因です。ぼくはイベントのライブ感が好きなので、登壇時はいつもメモを用意せず、即興で話しています。その緊張感が登壇の醍醐味だとすら思っています。今回もそうしてしまったのですが、翻訳にはふさわしくありませんでした。また機会があれば、そのときにはしっかり準備して臨みます。申し訳ありませんでした。運営メンバーへの感謝・尊敬最後に、このような機会を作っていただいた運営メンバーのみなさまに、あらためて感謝申し上げます。24時間連続のオンラインイベントなんて、事前の準備も当日のオペレーションも、イベント運営にほぼ携わったことのないぼくには想像を絶するご苦労があったかと思います。しかも、みなさんボランティアで運営されているわけで、その熱意には尊敬するばかりです。いろんなものをいただき、本当にありがとうございました。

JAWS PANKRATION 2024に登壇して得られたもの

VPoTの岩本 (iwamot) です。この記事では、AWS Lambdaを使わずにサーバーレスな処理を実装する、いわゆる「Lambdaレス」な実装の例をご紹介します。具体的には「AWSサービスのIPレンジ変更を検知し、AWS WAFのIPセットを自動更新してみた」例です。Lambdaレスな考え方は、AWS Summit Japan 2024のセッション「サーバーレス開発のベストプラクティス ～より効果的に、より賢く使いこなすために～」（動画、資料）で取り上げられ、注目されています。*1いざ実装してみると、Lambda関数の保守がいらなくなるメリットが大きく感じられました。Lambdaレス以前の実装例AWSは、AWSサービスのIPレンジ変更を検知し、AWS WAFのIPセットを自動更新するサンプルとして、下記のGitHubリポジトリを公開しています。github.comgithub.comいずれも、IPレンジ変更が通知されるSNSトピック (arn:aws:sns:us-east-1:806199016981:AmazonIpSpaceChanged) にサブスクライブしたLambda関数で、IPセットを更新する実装です。                          +-----------------+         +----------------+                          | Lambda          |         |                |                          | Execution Role  |    +--->+AWS WAF IPv4 Set|                          +--------+--------+    |    |                |                                   |             |    +----------------+                                   |             |+--------------------+    +--------+--------+    ||SNS Topic           +--->+ Lambda function +----+|AmazonIpSpaceChanged|    +--------+--------+    |+--------------------+             |             |    +----------------+                                   |             |    |                |                                   v             +--->+AWS WAF IPv6 Set|                          +--------+--------+         |                |                          | CloudWatch Logs |         +----------------+                          +-----------------+https://github.com/aws-samples/aws-waf-ipset-auto-update-aws-ip-ranges                          +-----------------+         +---------------------+                          | Lambda          |         |                     |                          | Execution Role  |    +--->+AWS WAF IPv4/IPv6 Set|                          +--------+--------+    |    |                     |                                   |             |    +---------------------+                                   |             |+--------------------+    +--------+--------+    ||SNS Topic           +--->+ Lambda function +----+|AmazonIpSpaceChanged|    +--------+--------+    |+--------------------+             |             |    +-------------------+                                   |             |    |                   |                                   v             +--->+AWS VPC Prefix List|                          +--------+--------+         |                   |                          | CloudWatch Logs |         +-------------------+                          +-----------------+https://github.com/aws-samples/update-aws-ip-rangesこれらのサンプルを活用してもよいのですが、できればLambdaレスにして、保守の手間をなくしたいですよね。Lambdaレスな実装例どうしたらよいのか、ぼくなりに考えて出た答えが下記でした。IPセットの更新にStep Functionsを利用トリガーにSQSとEventBridge Pipesを利用以下、説明します。IPセットの更新にStep Functionsを利用IPセットの更新は、AWS WAFのUpdateIPSet APIを呼び出して実行します。Lambdaレスで呼び出す手段として、ぼくはStep FunctionsのAWS SDK統合を選びました。具体的なワークフローは下記の通りです。{  "Comment": "Updates WAFv2 IP set with latest Route 53 health check IP ranges when AWS IP ranges change.",  "StartAt": "Parallel",  "States": {    "Parallel": {      "Branches": [        {          "StartAt": "GetManagedPrefixListEntries",          "States": {            "GetManagedPrefixListEntries": {              "End": true,              "Parameters": {                "PrefixListId": "pl-xxxxxxxxxxxxxxxxx"              },              "Resource": "arn:aws:states:::aws-sdk:ec2:getManagedPrefixListEntries",              "Type": "Task"            }          }        },        {          "StartAt": "GetIPSet",          "States": {            "GetIPSet": {              "End": true,              "Parameters": {                "Id": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",                "Name": "my-ip-set",                "Scope": "CLOUDFRONT"              },              "Resource": "arn:aws:states:::aws-sdk:wafv2:getIPSet",              "Type": "Task"            }          }        }      ],      "Next": "UpdateIPSet",      "Type": "Parallel"    },    "UpdateIPSet": {      "End": true,      "Parameters": {        "Addresses.$": "$[0].Entries[*].Cidr",        "Id.$": "$[1].IpSet.Id",        "LockToken.$": "$[1].LockToken",        "Name.$": "$[1].IpSet.Name",        "Scope": "CLOUDFRONT"      },      "Resource": "arn:aws:states:::aws-sdk:wafv2:updateIPSet",      "Type": "Task"    }  }}マネージドプレフィックスリストを参照しているのは、今回の要件が「Route 53ヘルスチェックで使われるIPv4レンジをIPセットとして提供すること」だったためです。pl-xxxxxxxxxxxxxxxxx で com.amazonaws.<region>.route53-healthchecks を参照し、エントリをAWS WAFのIPセットにコピーしています。Step FunctionsではHTTPリクエストも可能です。今回は試していませんが、Lambdaレス以前の実装のように、https://ip-ranges.amazonaws.com/ip-ranges.json を参照するワークフローも可能でしょう。ちなみに、UpdateIPSetの前にGetIPSetしているのは、その順で呼び出す仕様だからです。詳しくはUpdateIPSet APIのドキュメントをご覧ください。トリガーにSQSとEventBridge Pipesを利用ここまでできれば、あとはSNSとStep Functionsをつなぐだけです。SNSトピックに直接Step Functionsをサブスクライブできるとよいのですが、現時点ではできません。今回は「SNS → SQS → EventBridge Pipes → Step Functions」とつないでみました。EventBridge Pipesは、まさにこのような統合に使えるサービスです。https://aws.amazon.com/jp/eventbridge/pipes/おわりに以上、Lambdaレスな実装例をご紹介しました。Lambdaを「SQS → EventBridge Pipes → Step Functions」で置き換えているため複雑に見えるかもしれませんが、実際にはワークフローを組み立ててサービスをつないでいくだけです。実装してみて、Lambda関数の保守がいらなくなるメリットが大きく感じられました。今後も、Lambdaレスな実装をまず考えるようにします。*1:2024年8月23日から24日にかけて開催されるイベント「JAWS PANKRATION 2024」でも、AWSコミュニティビルダーの鈴木さんが「What is "Lambdaless" serverless?」を発表予定です。

「Lambdaレス」な実装例：AWS WAFのIPセット自動更新

スナップショットテストをやめて、ビジュアルリグレッションテストに移行した話

VPoTの岩本 (iwamot) です。この記事では、Terraformモジュール構成のベストプラクティスをご紹介します。Terraformドキュメントに書かれているものですが、従わずに時間を溶かした失敗談をまじえてお伝えすることで、同じ轍を踏む方が減ることを願っています。取り上げるのは下記のベストプラクティスです。Module Composition（フラットなモジュールツリー）Dependency Inversion（依存性の逆転）Module Composition（フラットなモジュールツリー）Module Compositionは、モジュールをフラットに並べられるよう構成すべし、という話です。Terraformドキュメントでは下記の例が挙げられています。module "network" {  source = "./modules/aws-network"  base_cidr_block = "10.0.0.0/8"}module "consul_cluster" {  source = "./modules/aws-consul-cluster"  vpc_id     = module.network.vpc_id  subnet_ids = module.network.subnet_ids}これに従わず、aws-consul-clusterモジュール内でnetworkモジュールを参照し、ルートモジュールで下記のように記述する設計も可能です。module "consul_cluster" {  source = "./modules/aws-consul-cluster"  base_cidr_block = "10.0.0.0/8"}ただ、後者の設計だと、たとえばnetworkモジュールの変数が増えたときにconsul_clusterモジュールにも追加しなければならず、保守の手間がかかります。モジュールの結合度が強すぎるわけです。ぼくが設計を失敗したのは、モジュールAとモジュールBの共通部分をモジュールCに切り出し、内部的に参照させたケースでした。開発途中で変数の引き回しが面倒になり、結果的にModule Compositionに従うこととなりました。最初から従っていれば、無駄な工数が省けたはずです。Dependency Inversion（依存性の逆転）モジュールがフラットになれば、下記のような記述も可能になります。data "aws_vpc" "main" {  tags = {    Environment = "production"  }}data "aws_subnet_ids" "main" {  vpc_id = data.aws_vpc.main.id}module "consul_cluster" {  source = "./modules/aws-consul-cluster"  vpc_id     = data.aws_vpc.main.id  subnet_ids = data.aws_subnet_ids.main.ids}つまり、networkモジュールを使わずとも、consul_clusterモジュールが使えるわけです。このように、モジュールで必要となるリソースをルートモジュールから渡す設計が「Dependency Inversion」です。ぼくはこの点も考慮が不足していて、前述のモジュールCにおいて、モジュールA・Bのリソース命名規則に依存した処理を記述してしまいました。Module Compositionに従って構成をフラットに変えたものの、結合度の強さは変わらぬままでした。命名規則が変わるたび、モジュールCにも手を入れなければなりません。そこで、モジュールCで必要となるリソースを、モジュールA・Bから渡してもらう設計に見直しました。Terraformドキュメントにあるように、object型の変数を定義すると、リソースが渡しやすくなります。variable "ami" {  type = object({    # Declare an object using only the subset of attributes the module    # needs. Terraform will allow any object that has at least these    # attributes.    id           = string    architecture = string  })}アンチパターン：リソースがなければ作成するまた、Terraformドキュメントでは「リソースがなければ作成する」（Conditional Creation of Objects）設計も避けるよう勧めています。もし不足しているリソースがあれば、ルートモジュール側で作成するほうが、あとで読む人が理解しやすいためです。ぼくはこの点も考慮不足で、条件式の結果を count に代入し、リソースを作ったり作らなかったりする記述をしていました。ただ、当該リソースを参照するのに条件式をいろんな場所で書かなければならず、不便でやめました。こちらも最初から従っていれば、無駄な工数が省けたはずです。まとめ以上、Terraformモジュール構成のベストプラクティスを、ぼくの失敗談をまじえてお伝えしました。結論として、下記の点に気をつけるとよいでしょう。他のモジュールに依存したモジュールは作らない条件式に依存したリソース作成はなるべく避ける（作成後に参照しないならOK）ぼくも、またTerraformモジュールを作る機会があれば気をつけます。

Terraformモジュール構成のベストプラクティス

ENECHANGEのI/O Dayは、新しい技術の習得と活用を促進するための社内イベントです。参加者の目的は、未経験の技術や新しいツール、他事業部で採用されている技術について学び、それをアウトプットを通じて共有することです。VPoT 岩本隆史I/O Dayを通じて技術革新の促進を！ 開催の経緯と目的ーー I/O Day導入の経緯について教えてください岩本：I/O Dayは、エンジニアの開発者体験を向上させるための取り組みとして導入されました。まず、社内で開発者体験をどう向上させるかについてのアンケートを実施しました。その結果、社内のエンジニアから「Googleの20%ルール」のような施策が欲しいという意見が寄せられました。この意見をもとに、私が中心となって具体的な計画を立て、I/O Dayの実現に向けて動き始めました。こうして、エンジニアが新しい技術を学び、業務に活かす機会を提供するI/O Dayが実現しました。ーー I/O Dayの特徴とは何ですか？岩本：I/O Dayの主な特徴は以下の4つです。最新技術の探求知識の深化と共有実践的な学び組織の技術レベルアップへの貢献ーー 続いて、I/O Dayの目的について教えてください！岩本：I/O Dayの開催の目的は以下の2つです。所属エンジニアの開発者体験向上エンジニアの採用強化I/O Dayの開催は、ENECHANGEがエンジニアにとって魅力的な企業となるための一歩です。このイベントを通じて得られた知識や技術は、日々の仕事やプロジェクトに直接役立ち、新しいアイデアの創出や会社全体の競争力の向上にも繋がります。I/O Dayの案内資料I/O Dayイベントを通じた社員の意見把握ーー I/O Day 参加対象者と成果物について教えてください！岩本：今回のI/O Dayの参加対象者は、各事業部（エネチェンジ事業部、エネルギークラウド事業部、EV充電サービス事業部）に所属するエンジニアであり、マネージャーは対象外としています。初めての試みであるため、できるだけ多くのエンジニアに参加してもらい、このイベントが本当に価値のあるものかどうかを評価することを目的に、全員に必須参加をお願いしました。エンジニアたちは事業部の垣根を越えて協力し合い、初回のI/O Dayの日程を5月15日に合わせるための調整や、専用のSlackチャンネルを作成するなど、積極的な姿勢を見せてくれました。また、初回のI/O Dayでは、個人ブログの投稿や社内LTの実施など、多様なアウトプットが見られました。Q3以降もI/O Dayを継続するかどうかは、参加者からのフィードバックに基づいて決定されます。エンジニアたちの成長と企業全体の技術力向上に寄与するイベントとして、I/O Dayが定着することを目指しています。ーー I/O Dayに参加するとどんなメリットがありますか？岩本：業務に没頭していると、自分の成長を実感しにくいことがありますよね。例えば、プロジェクトが3ヶ月間に及ぶ場合に同じ業務を淡々とこなしているだけだと、自分の成長が遅れているのではないかという不安が生じます。そんな不安を払拭し、さらなる成長を促進するために、I/O Dayは非常に価値のある機会だと感じています。I/O Dayに参加することで得られるメリットは、大きく3つあります。自分の成長を実感できる　日々の業務では、目の前のタスクに追われ、自分の成長を実感しにくいことがあります。しかし、I/O Dayでは、最新技術やトレンドに触れ、様々なセッションに参加することで、短期間で幅広い知識とスキルを習得することができます。本当にやりたい仕事を見つけられる　仕事においては、本当にやりたいことができることに大きな価値があります。I/O Dayでは、自分が興味を持ち、情熱を持って取り組める仕事を見つけることができます。新しい技術の習得や問題解決能力の向上が見込める　新しい技術やツールを実際に手を動かして学ぶことで、様々な場面での活用可能性や問題解決能力の向上につながります。　I/O Dayを成功に導くためにとった具体的なアクションーー I/O Dayのテーマ設定方法はどのようにされていますか？岩本：今回私は、I/O Dayの開催を推進したものの、具体的なテーマ設定には関与しませんでした。エンジニアたちは自身でやりたいテーマを決め、マネージャーに許可を得て参加しています。今回のI/O Dayでは、業務に関連し、今後取り組むべきテーマを選定して進めるようお願いしました。多くのエンジニアが、業務をしている上で気になっているが手がつけられていないテーマに取り組みました。具体的には以下の項目です。未導入技術の評価トイルの削減オンボーディングプロセスの改善また、アウトプットに対しては必ずCTO室からコメントをするようにし、エンジニアの成長とモチベーションの向上を図っています。ーー I/O Dayを実施してみて課題はありましたか？岩本：I/O Dayを最初に提案した際、アウトプットの具体的な内容については考えていませんでした。しかし、成果が目に見えないという意見もあり、参加者にはアウトプットも求めることにしました。ですが、1日でアウトプットまで完了するのは難しいという現実も見受けられたため、今後は1日のインプットと別の日にアウトプットを行うようなスケジュールも検討する余地があると感じています。また、期間が短いとやりたいことのテーマ選定の幅が狭くなるリスクもあります。参加者が自分の興味や得意分野に応じて取り組めるテーマを広げることが重要だと考えています。エンジニアがよりI/O Dayを満足できるようにーー I/O Dayの今後の展望について教えてください岩本：まずは、I/O Dayを実施して良かったと感じています。参加者からの意見を参考にして、今後さらに改善していきたいと考えています。I/O Dayを実施する目的は開発者体験の向上と社外へのアピールです。そのため、今後は参加者がより満足できるような取り組みを積極的に導入していきたいと思っています。特に、エンジニアにはテックブログを書いてもらいたいと考えています。これにより、社内外へのエンジニアに技術的な知見を共有し、企業の技術力向上に寄与できると考えています。私自身が直接お願いして、積極的にブログの執筆を進めていきたいと思っています。最後に、I/O Dayを社内の声を反映させて実施できたことが非常に良かったです。意見を出してくれたメンバーにも感謝しています。（以上）参考記事I/O Dayのエンジニアの具体的アウトプットについては、本ブログにいくつか記事があります。よかったらこちらもご覧ください。tech.enechange.co.jptech.enechange.co.jp