ENECHANGE Developer Blog

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

ENECHANGEの新たな取り組みI/O Dayとは？ 技術革新の現場をインタビュー！

ENECHANGEの Yuto Ono です。エンジニアリングマネージャーをしながら、フロントエンドの開発もしています。React を使った開発で悩むポイントの1つとしては、 useEffect の使い方だと思います。何でもできる魔法のようなフックですが、それゆえに、間違った使い方をされることも多い印象です。そこで今回は、最近遭遇した useEffect のアンチーパターンと、それの対処法を紹介していこうと思います。こちらの公式ドキュメントに、さらに詳しく書いてありますので、詳しく知りたい方はこちらをご参照ください。ja.react.devなお、最近のフロントエンド開発では TypeScript を使うことが多いですし、弊社でも TypeScript を使っていますが、今回は型についての話はしないので、 JavaScript でコードを記載しています。useEffect のアンチパターンとしてよく取り上げられるのが、他の props や state から計算できるものを、新たな state を用意して useEffect の中で更新してしまう例です。function Component({ firstName, lastName }) {  // ダメ  const [fullName, setFullName] = useState('');  useEffect(() => {    setFullName(firstName + ' ' + lastName);  }, [firstName, lastName]);  // ...}こちらのコードが良くないのは、ぱっと見て気づく方も多いのではないでしょうか。なぜダメかというと、この書き方だと余計なレンダリングが発生しパフォーマンスが悪化するprops が更新されたタイミングで1回目のレンダリング1回目のレンダリングで発火した useEffect 内の state 更新により2回目のレンダリングコードが必要以上に複雑になり可読性が低下これを改善すると下記のようなコードになります。function Component({ firstName, lastName }) {  // Good  const fullName = firstName + ' ' + lastName;  // ...}こちらの方がシンプルですし、パフォーマンスも良くなりますね。この程度であれば、一定の実力のあるエンジニアはほとんどこのようなミスはしないのですが、複雑なパターンになると、意外と経験者でもアンチパターンで実装してしまうことがあることに最近気がつきました。最近のコードレビューで指摘したケースは、簡単に書くと、以下のようなコードでした。function Component({ firstName, lastName }) {  // ダメ  const [fullName, setFullName] = useState('');  useEffect(() => {    if (firstName === '') {      setFullName(lastName);    } else {      setFullName(firstName + ' ' + lastName);    }  }, [firstName, lastName]);  // ...}確かに、条件分岐などのロジックが入って、1行で書けなくなると、つい useEffect を使いたくなる気持ちもわかりますし、実際のコードはこれよりももっと複雑だったりします。しかしよく考えると、これも他の props や state から計算できるという点で、最初に掲載したアンチーパターンと本質的には変わりません。これに対する自分なりの筋の良い対処法は2つあります（もちろん他にも方法はあると思います）。1) fullNameを計算する関数を作るfunction calcFullName(firstName, lastName) {  if (firstName === '') {    return lastName;  }  return firstName + ' ' + lastName;}function Component({ firstName, lastName }) {  // Good  const fullName = calcFullName(firstName, lastName);  // ...}こっちの方がシンプルでコードの意図も伝わりやすくて良いですね！ 僕もよく使う方法です。2) useEffect の代わりに useMemo を使うfunction Component({ firstName, lastName }) {  // Good  const fullName = useMemo(() => {    if (firstName === '') {      return lastName;    }    return firstName + ' ' + lastName;  }, [firstName, lastName]);  // ...}useMemo を使うことにより他の state や prop から値を計算しているという意図が伝わりやすく、良いですね。もしかしたら、わざわざ（計算量的に）メモ化する意味あるの？というツッコミが入りそうなので念のため補足しておくと、確かに公式ドキュメントにもある通り、よっぽど重い処理でなければ、メモ化による最適化の恩恵を受けることはありません。とはいえ、useEffect と違って余計なレンダリングが発生しない点や、可読性が向上するなどのメリットを考えると、十分に使う価値があるのではないかと思っています。また公式ドキュメントにも過度なメモ化を行うことによる重大な害はないとはっきり書いてあるので、迷ったら使うぐらいのスタンスで問題ないと思っています。以上、最近見かけた useEffect のアンチーパターンとその対処法の解説でした。ぜひ今後の参考にしていただければ幸いです！

最近遭遇した useEffect のアンチパターンを紹介 【React】

はじめに初めまして！2024年2月からWebエンジニアとしてENECHANGEの就業型インターンに参加している植月です。現在は大学院修士2年生で計量経済学系の研究室に所属しており、普段は主に一人、チーム問わずWeb開発をしています。約半年間、インターン生としてENECHANGEで働くことで学んだことや感じたことを書いていこうと思います。参加したきっかけENECHANGEさんと初めて接点を持ったのは、とある面談イベントでCTOの有田さんとお話しをさせていただいた時です。いきなりCTOの方と話すのはとても緊張したのですが、滅多にない機会、かつ就活中だったということもありいろんな人の話を聞いておいたほうがいいだろうと思い参加させていただきました。面談ではChatGPTがソフトウェア開発をどのように変えていくか、今後ENECHANGEをどうしていきたいかといったお話を熱く語っていただいたことを覚えています。とても面白そうな事業内容かつ、素敵な人柄に惹かれ、その後のアンケートでもう一度面談を希望する旨を伝えると、後日、再度面談を組んでいただき、その後インターンに参加することが決まりました。インターン業務内容ENECHANGEはEVsmartという日本に存在する電気自動車の充電器スタンドを検索できるサービスを展開しています。自分の担当領域はそこで表示される充電器等のデータを、社内のデータ管理チームが扱えるようにするための社内ツールの開発です。実はこのメンテナンスツールはversion2からversion3に移行中で、担当開発陣は近々本番環境で使用されることになるversion3の開発を主に行っています。使用技術はバックエンドがGolang、フロントエンドがNext.jsで、チーム全員がフルスタックに開発を進めています。自分もバックエンド、フロントエンド問わず様々なタスクをアサインされています。また、自分のチームではスクラム開発というものを採用しており、小規模なチームが短期間のスプリントと呼ばれる期間を設定し、その期間内であらかじめ目標として設定した成果物を生み出すサイクルを繰り返していきます。自分のチームでは2週間を1スプリントとしており、隔週金曜日にスプリントレビューという、データ管理チームにスプリント中に追加した機能などを説明する時間が設けられていました。インターンで得られた経験業務レベルの実装コードに触れる機会自分が今まで携わってきた開発では、年季が入っており技術負債が積み上がっているものや、個人で開発した無茶苦茶なコードがメインだったため、インターンに初めて参加した時はコードの読みやすさに感動したのを覚えています。同チームのエンジニアの方々はシニアレベルの技術力を有しており、実際に彼らのコードを一行一行読み解く過程で、ただ言語・フレームワークの理解だけではなく、ドキュメントにないドメイン知識についても自然と理解することができていました。Golangに関する知見自分はENECHANGEでインターンをするまでGolangについての知見がなかったのですが、業務で使用&勉強会に参加したことで、業務に支障をきたさない程度ではありますが、問題なく使用できるようになりました。また、自分のチームではGinというフレームワークを使用しているのですが、Ruby on RailsやLaravelといったフルスタックなフレームワークと比較すると自由度が高く、開発者側がある程度アーキテクチャの設計を行わなければなりません。DDDやアーキテクチャ等の概念を押さえた上で開発を進める必要があるため、そういった意味でもスキルアップした実感があります。インターンのいい点インターン生としてではなく一人のエンジニアとして扱ってくれるこれまで自分が参加したインターンでは、インターン生のためのタスクがあらかじめ作成されており、期間中はそのタスクにアサインされるものが多かったのですが、ENECHANGEではプロジェクトを進めるにあたって、その都度必要なタスクが振られます。またこれは任意ではありますが、毎週開かれている職種を跨いだミーティングにも参加することができます。自分の今行っているプロジェクトの位置付け、他チームのプロジェクト内容、ビジネス職の人たちとの関わりなど、学生ではなかなか見ることのない、会社内部の動きを垣間見ることができます。社員の方々と話す機会ENECHANGEでは所属部署ごとに優先出社日というものがあり、自分の所属は毎週水曜日に出社が推奨されています(必須ではありません)。自分も都合がつく日はなるべく出社しています。出社した日はお昼時になると社員の方々とランチにいくのですが、職種を問わずいろんな人とお話しする機会があります。他チームのエンジニアの方からビジネス職の方、執行役員、CTOといった様々な方とお話しさせていただくことで、自分が社会に出てから何をしたいか、どのようになっていたいか、改めて考えるきっかけになりました。最後に基本リモートでのインターンですが、わからないことがあってもマネージャーの方はもちろん、チームメンバーやその他の社員の方々に丁寧に質問対応していただいているおかげでとても快適に開発することができています。非常に学びのあるインターンであるため、ご興味がある方は是非ENECHANGEのインターンに参加してみてください。インターンの詳細は下記リンクをご参照ください。newgrads.enechange.co.jp最後までお読み頂きありがとうございました。

インターン生として半年間ENECHANGEで働いてみて

こんにちは、EV充電サービス事業部でFlutterエンジニアをしている小林です。2023年12月に弊社とSmart Shopping様と共同で「IoT系のプロダクト開発の裏側」というテーマのオフライン勉強会を開催いたしました。その中で「事業譲渡を受けたアプリとの統合で失敗、 そしてユーザーからの評価回復に至るまで」というタイトルで発表した内容を、改めてブログ記事としてまとめます。また、その後日談についても触れようと思います。enechange-meetup.connpass.com背景ENECHANGEでは2022年春にEVの充電サービスとアプリをローンチしました。このアプリのコアとなる機能はもちろんENECHANGEが設置する充電器で充電することです。しかし私たちが目指しているのは、すべてのEVドライバーにとって価値のあるアプリになることです。そのためにも自社設置の充電器だけではなく、日本中のあらゆる充電スポットを探すことのできるアプリになる必要がありました。その目的を果たすため、ENECHANGEは2022年9月にアユダンテ株式会社のEVsmartという事業を譲り受けました。EVsmart事業では独自に収集した日本中の充電スポットを網羅したデータベースと、それを探すことのできるモバイルアプリを提供していました。この事業譲受のニュース掲載とほぼ同じタイミングで、私はENECHANGEにFlutterエンジニアとして内定をいただいただきました。しかも、EVの納車直前でEVsmartアプリを使って付近の充電環境を調べていた最中だったため、このニュースにはとても驚き、そしてワクワクしたのでした。入社早々、私はEV充電エネチェンジアプリとEVsmartアプリの統合プロジェクトにアサインされ、この２つのアプリの統合を主導することになりました。この時点で両アプリの機能差分が一覧化されており、EV充電エネチェンジアプリの方に不足機能を移植していくという方針までが決まっている状態でした。アプリ統合のための泥臭い取り組みアプリ統合に取り組み始めて最初に突き当った壁は、EVsmart事業の複雑性でした。EVsmartアプリはEV充電エネチェンジアプリに統合することが決定していましたが、EVsmartアプリと同等の機能をもつウェブサイトやOEMアプリなど提供しているプロダクトが多く、かつそれらは同じバックエンドを参照していました。つまり、統合のために機能に手を加えると、それらのすべてのサービスに影響してしまうのです。このような複雑性から、開発チーム内での設計の議論が停滞してしまい、前に進まない状態に陥ってしまいました。事業目線ではEVsmartアプリのユーザーにエネチェンジの充電器を使ってもらいたく、アプリ統合もなるべく早く終える必要があります。しかしながら統合はそんなに簡単なものではありません。そのため、EVsmartアプリの方にEV充電エネチェンジの充電スポット情報を掲載し、かつその画面からEV充電エネチェンジアプリへ誘導するディープリンクを設置することにしました。これで自社充電器への集客もある程度でき、統合までの時間かせぎとなりました。確保した時間で改めて複雑性に向き合いました。これは本当に泥臭い作業です。EVsmartアプリとそのサーバーサイド、EV充電エネチェンジアプリとそのサーバーサイド、その両方のシステム構成や設計を把握するため、とにかくEVsmart事業と自社のエンジニアにたくさんの質問をしました。そしてアプリ・サーバーサイド問わず、あらゆるコード（PHP、Ruby on Rails、Swift、Kotlin、Dart、・・・）を読みました。最初は大海を泳いでいるような感じでしたが、だんだん島の輪郭が見えるようになってきました。把握できたシステム構成などはなるべくわかりやすい図におこし、開発に関わるメンバーが誰でも理解できるような状態にしました。これにより「現状がこうなっているなら、このようにシステム間を繋ぐといいね」といった議論がようやく進むようになってきました。前述のとおりアプリ統合の都合だけで機能に変更を加えてしまうと、関連するプロダクトに影響が出てしまいます。その影響を最小限にするため、EVsmartのバックエンドは極力変更せずに統合を進める方針に決めました。システム構成を紐解いたことで、定期的なデータベース同期を行うことと、EV充電エネチェンジアプリのAPIサーバーが、EVsmartのバックエンドとの仲介役となれば、一通りうまく統合できそうだという目処がついたのです。このような苦労の末、2023年6月末に予定通り統合したアプリをリリースすることができました。しかしこの時点で重要な点を見逃していることに私たちは気づけていませんでした。リリース後にアプリストア評価が⭐️１に...リリース後、多くのEVsmartアプリユーザーから元のアプリに戻してほしいという声をいただきました。その声はすぐさまアプリストアの評価にも表れ、iOSアプリは⭐️1.4まで下がってしまうことになりました（iOSは統合のタイミングでストア評価のリセットをしてしまったことも影響しています）。EVsmartアプリもEV充電エネチェンジアプリも統合前は⭐️3〜4で一定の評価をいただけていた状態だったのですが、一体何が起きてしまったのでしょうか。EVsmartのみ提供していた機能については、概ねEV充電エネチェンジアプリへの移植ができていましたし、リリース後も目立った不具合は出ていません。EVsmartアプリからEV充電エネチェンジアプリへのユーザー移行も社内のEVsmartヘビーユーザーが驚くほどにシームレスにできたという自負もあります。しかし私たちはEVsmartアプリのコアバリューである「マップで充電スポットを簡単に探せる」というUXレベルの高さを見逃していたのでした。マップで充電スポットを探すための機能一覧ではその差はほとんどありませんでしたが、それぞれの機能の使いやすさはEVsmartアプリに比べると劣る部分が多い状態でした。また、EVsmartアプリユーザーにとってはUIが大きく変化してしまったことも影響していたと思います。アプリストア評価回復のための泥臭い取り組み開発チームはストアの評価回復を最優先課題として取り組むことになりました。まずはユーザーからの声をすべて集めることから始めました。アプリストアへのレビュー投稿やカスタマサポート窓口への問い合わせ、Twitter（現在のX）などのSNSへの投稿（毎日エゴサーチ）、社内のEVドライバーやその知り合いからの声、そしてEVsmart事業譲受前のプロダクトオーナーからの意見、それらすべてを集約しました。集まった声は約250件。これらすべてに目を通し、整理・分類してどの問題から解消すべきか優先度づけを行いました。また、自動的に集められるものは事業部のSlackにも通知し、この現状を事業部メンバーが肌で感じることで、対応の温度感を高めました。対策検討には社内のEVドライバーも巻き込み、いただいた声の本質的な問題は何かをEVドライバー目線で理解するように努めました。そして、優先度の高いものはなるべくミニマムに改善してすぐにリリースするようにしました。根本的な問題解消には時間がかかるようなものでも、少しの改善でその問題の半分でも解消されるのであればそれでリリースするというスタンスです。なるべく早くユーザーの痛みを少しでも解消したかったのです。統合したアプリのリリース後、毎週の頻度でアプリの改善版をリリースし、約2ヶ月間で7回のリリースを行いました。また、リリース内容はSNSを通じてもユーザーに伝えるなど、ユーザーとのコミュニケーションも強化しました。このような取り組みが徐々にユーザーに受け入れられ、SNSでも好意的な意見をいただけるようになりました。それまでは厳しい意見が続いていましたたが、その穴から一旦脱出できたという実感がありました。ここまでの取り組みにより、充電スポットを探すというUXレベルもEVsmartアプリに近いものになりました。改善活動の中で「急速充電スポットはマップのピンでその最大出力を表示する」というEVsmartアプリにはなかった機能を開発したのですが、それは特に多くのユーザーから好意的な声をいただくことができました。しかしながらアプリストアの評価は大きく回復しませんでした。ネガティブな評価に比べるとポジティブな評価は待っていてもつきにくいものです。であればこちらから評価をいただけるように対策する必要があります。その頃ちょうど弊社ではEV充電エネチェンジのPRのためにEVドライバーが集まるイベントへの出展をはじめていました。そこで、開発メンバーも参加しユーザーの声を直接伺いにいくことにしました。イベントに集まってくださるEVドライバーの方には、現状のアプリへの率直なフィードバックとストアの評価を依頼しました。ご意見をいただけた方には、それがポジティブ・ネガティブどちらであるかに関わらず、ノベルティのプレゼントでお礼させていただきました。結果としては、改善したアプリはポジティブに受け入れられており、⭐️4,5といった評価をたくさんいただくことができました。また、この2ヶ月でやってきた改善活動を見ていてくださったユーザーから温かい声をかけていただけたことで励みになりましたし、さらに良くするためのアドバイスをいただいたりと、とても貴重で有意義な機会となりました。直接的な評価回復策ではありませんが、ストア評価の変化を毎日自動的にチェックしてSlackの事業部チャンネルに投稿するようにしました。高めの評価がいただけるようになったことで、日々数字が改善していく過程を社内に伝えることができました。開発チームのモチベーションにもつながったのも良かったです。イベントでの評価獲得はとても効果が高かったのですが一時的なものですので、継続的に新規ユーザーの評価が得られるような仕組みも必要です。そして、ユーザーが本当にアプリで良い体験をしたと感じてもらえた時に評価を依頼できるのがベストだと思います。幸いなことにEV充電エネチェンジには「アプリで簡単に速く充電してもらう」というコアバリューがありました。ENECHANGEでは、現時点で広く普及している普通充電器の倍の出力を持つ充電器のみを設置しており、この強みはどんなEVドライバーにも魅力的なものでした。そこで、ユーザーにとって満足する充電ができたと思われるタイミングでアプリから評価を依頼するようにしました。このような策がしっかり機能したおかげで、アプリを統合して５ヶ月後（2023年12月）までに300件近い評価をいただき、⭐️3.5まで回復させることができました！まとめこのEVsmartとEV充電エネチェンジアプリの統合プロジェクトを経て、統合する両アプリが提供する価値のレベルを下げてはならないということを学びました。今から思えばですが、リリース前に十分なベータテストを行えていれば、リリースを中断するような判断もできたでしょうし、そもそも統合プロジェクトにおけるプロダクトマネジメントが機能するような体制構築ができていれば良かったな、など反省点はたくさんあります。この失敗経験を今後の開発に活かし、より良いプロダクトをユーザーに提供していきたいと考えております。この失敗後のアクションはとても良く機能したと思います。やはりユーザーが何に困っているのかを正確に把握し、その痛みを的確に解消していくような改善活動はユーザーにしっかり伝わります。大きな機能追加も大事ですが、細部の質を上げていくこともユーザーの評価につながることを実感できました。また、アプリのポジティブな評価を得るには待っているだけではダメで、アプリのコアバリューの部分を武器に評価をもらいにいくような取り組みが必要であることもわかりました。そのためにも、アプリに明確なコアバリューがあることは必要条件となりますし、それを磨き続けていくことも重要なのです。そして、私たちのコアバリューは誰にとっても使いやすい持続可能なEV充電インフラを提供することです。EV充電エネチェンジではこれからもこのコアバリューを磨き続けていきますので、応援していただけると幸いです。後日談オフライン勉強会でのこの発表から約半年が経過しました。この間も充電インフラ環境づくりのためのユーザーを巻き込んだ取り組みである「エネチェンジサポーターズ」発足や、この6月初には日中の電力を有効活用した定額プラン「エネチェンジパスポート」といった新しい価値提供のための機能開発を進めてまいりました。もちろん細かな改善活動もEVドライバーイベントへの参加も続けております。2024年4月にテスラオーナーズクラブ主催の全国ミーティングに参加した時の様子おかげさまでアプリストアでも安定的に高い評価をいただけるようになっており、iOS・Androidともに ⭐️4.1 に到達いたしました！これもEV充電エネチェンジを応援してくださる皆様のおかげです。重ねてになりますが、EV充電エネチェンジは誰にとっても使いやすい持続可能なEV充電インフラを拡大すべく尽力してまいりますので、引き続き応援のほどよろしくお願いいたします！アプリストア評価の推移

事業譲渡を受けたアプリとの統合で失敗、 そしてユーザーからの評価回復に至るまで

こんにちは、ENECHANGEの園木です。設定ファイルも用意していますので、興味がある方はぜひ目を通してみてください。CodeRabbitとは？CodeRabbitは、自然言語モデルAIを使用してGitHubプルリクエストのコードレビューと要約を行います。HP: https://coderabbit.ai/ja/GitHub: https://github.com/coderabbitai/ai-pr-reviewerしくみCodeRabbitはGitHub Actionsを用いてAIレビューをおこないます。出力されるものCodeRabbitを導入した場合の実際のアウトプット物を紹介します。1. リリースノートPRコメントの末尾にPRの目的レベルでの説明が記載されます。New Feature：新機能Bug Fix：バグ修正Documentation：ドキュメントRefactor：リファクタリングStyle：スタイルTest：テストChore：雑務Revert：取り消し今回は「CodeRabbitを実装する」という内容なので新機能として説明されています。この箇所はGitHub Actionsが走るたびに内容が更新されます。2. 要約PRの差分を要約します。画像はオリジナルから項目を変更したものです。要約PR全体の変更点を完結に説明してくれます変更点差分ファイルごとにどのような変更がなされたかを要約してくれますこの箇所はGitHub Actionsが走るたびに内容が更新されます。3. コードレビュー差分を元に、AIがコードレビューをしてくれます。レビューのサマリー指摘箇所のレビュー指摘箇所のレビューという形式でコメントが追加されます。プロンプトに沿ったレビューをするので、各チームごとに視点を言語化しておくと良さそうです。準備GitHub Actions実行ファイルの作成.github/workflows配下にGitHub Actions用のyamlファイルを作成します。.github/workflows/code-rabbit.yamlにしました。OpenAI API KEYの設定下記URLにてOpenAIのAPI Keyを取得します。https://platform.openai.com/api-keyshttps://github.com/username/repository-name/settings/secrets/actions OPENAI_API_KEYを新規で作成し、OpenAI API Keyを設定します。デフォルトでの実行https://github.com/coderabbitai/ai-pr-reviewer?tab=readme-ov-file#install-instructions  code-rabbit.yamlを設定し、CodeRabbitが起動するかどうかを確認します。無事にGitHub Actionsが走り、CodeRabbitによるレビューが追加されたらひとまずの実装は完了です🎉最終的なファイルまずは完成形から見せてしまいます。code-rabbit.yamlは最終的に以下のようになりました。設定ファイルname: CodeRabbitpermissions:  contents: read  pull-requests: writeon:  pull_request:    types: [opened, ready_for_review]concurrency:  group:    ${{ github.repository }}-${{ github.event.number || github.head_ref || github.sha }}-${{ github.workflow }}-${{ github.event_name == 'pull_request' && 'pr_event' || 'pr' }}  cancel-in-progress: ${{ github.event_name != 'pull_request' }}jobs:  review:    runs-on: ubuntu-latest    steps:      - uses: coderabbitai/ai-pr-reviewer@latest        env:          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}          OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}        with:          openai_light_model: gpt-4o          openai_heavy_model: gpt-4o          language: ja-JP          summarize: |            次のmarkdownフォーマット形式を使用して、本PRの要約を出力します。            [出力形式]            ## 要約                        ## 変更点            以下では、デフォルトから変更した項目について説明します。トリガーの設定を変更する（GitHub Actionsの設定）デフォルトの状態では新規PRが作成されたときpushされたときで毎回ワークフローが走ってしまうので、以下のタイミングをトリガーにしました。新規PRが作成されたときPRがDraftからOpenに変わったときこれにより、開発者の任意のタイミングでAIレビューをすることができます。CodeRabbit独自の設定項目jobs:  review:    steps:      with:配下に独自に設定できる項目があります。https://github.com/coderabbitai/ai-pr-reviewer/blob/main/action.yml openai_light_model, openai_heavy_modelレビューに使用する言語モデルを指定することができます。openai_light_modelとopenai_heavy_modelは以下のように使い分けられているようです。openai_light_model変更点の要約など、軽微なタスクopenai_heavy_modelレビューやコメントといった複雑なタスク参考デフォルトではgpt-3.5-turboとgpt-4になっています。gpt-4oに変更しました。openai_light_model: gpt-4oopenai_heavy_model: gpt-4o理由は以下です。GPT-3.5での要約は信頼性と再現性が低いGPT-4よりもGPT-4oの方が高性能かつ安価参考: 言語モデル別の価格https://openai.com/api/pricing/languageレビューの言語を設定します。language: ja-JPちなみに、この項目で言語設定しておけばプロンプトを日本語訳して設定し直す必要はないハズです。summarizeデフォルトで指定されているWalkthroughという言葉に馴染みが無かったので要約に変更しました。Poemが入ってるので、削除しました。出力形式をマークダウンフォーマットで指定し、各項目で何を出力するのかはコメント形式で指定しました。その他の設定その他にも設定可能な項目がいくつかありました。path_filtersCodeRabbitによるレビューをスキップするファイルdisable_reviewデフォルト値: falsetrueにすることでレビューをスキップさせることが可能disable_release_notesデフォルト値: falsetrueにすることでリリースノートの作成をスキップさせることが可能openai_model_temperatureデフォルト値: 0.050-2の範囲で変更可能。大きくするとより不確実性が増すtempratureって何？という方はこちらsystem_messageCodeRabbitのシステムプロンプトどんな観点でレビューして欲しいのかを設定可能summarize_release_notesリリースノート作成用のシステムプロンプト実際どうなの？実案件で作成されたPRをCodeRabbitにレビューさせた感想は以下です。nil対策をしてくれるnilに対するエラーハンドリングをしていない箇所に対して指摘してくれましたタイポを指摘してくれるメソッド名のタイポを指摘してくれました全体的にtoo muchなレビューではありますが、「指摘された箇所の修正が不要であること」をPR作成者がコメントした上でレビュワー（人間）に渡すことでコードの理解度は増すと思います。また、CodoRabbitが作成した文章はすべてマークダウンで書かれているので、これを編集することで人間がゼロから書く作業コストを削減できます。個人的な結論としては、CodeRabbitは現状でも十分に活用可能なレベルであり、導入することで得られるメリットの方が大きいと感じています。ENECHANGEでは成長意欲の高いエンジニアを募集しています！弊社はエネルギーの未来をつくるというミッションを掲げています。www.wantedly.com参考https://zenn.dev/minedia/articles/7928ef7545b393

AIレビューツールであるCodeRabbitを試してみました【設定ファイルあり】

VPoTの岩本 (iwamot) です。ENECHANGEは、2024年3月にAWSパートナーになりました。パートナーパスとして「ソフトウェアパス」を選択しており、将来的にファンデーショナルテクニカルレビュー (FTR) の通過を目指します。aws.amazon.com今回は、ENECHANGEがAWSパートナーになった意図をかいつまんでご紹介します。AWSパートナーはメリットだらけ意図といっても単純で「メリットだらけ」だからです。具体的に、ENECHANGEの期待しているメリットには下記があります。AWS認定の新規取得によるクレジット毎年もらえる3,500ドルのクレジットFTRによるワークロードの改善、認知度の向上AWS認定の新規取得によるクレジットまず「AWS認定の新規取得によるクレジット」について、AWSは下記のように説明しています。・AWS 認定資格新規取得時に AWS クレジットクーポンを進呈( アソシエイト認定取得につき $300 / プロフェッショナルまたは専門知識認定取得につき $500 )APN パートナーになる “３ つの理由” とは | AWS JAPAN APN ブログ実際、ぼくは3月30日にAWS Certified Advanced Networking - Specialty試験に合格しており、500ドル分のクレジット（プロモーションコード）が4月17日にメールで届きました。そのメールによれば、3か月に1度付与される運用のようです。届いたクレジットは、マネジメントコンソールで適用できます。毎年もらえる3,500ドルのクレジット次に「毎年もらえる3,500ドルのクレジット」についてです。AWSは下記のように説明しています。APN セレクトパートナー以上の皆さまは、毎年の更新時に年会費 ($ 2,500) をお支払い頂いていますが、同時に $ 3,500 (アドバンスドパートナーは $ 5,000 ) の AWS クレジットクーポンでお返しさせて頂いています。APN パートナー様の自社システムや開発環境などでご活用頂けます。APN テクノロジーパートナー “10 のメリット” をご紹介！ | AWS JAPAN APN ブログつまり、年会費の2,500ドルを差し引いても、1,000ドルのプラスになるわけです。日本円だと現時点で157,500円ほどのプラスになります。年会費は6月4日に支払っており、クレジットが届くのを待っているところです。FTRによるワークロードの改善、認知度の向上最後に「FTRによるワークロードの改善、認知度の向上」についてです。AWSは下記のように説明しています。FTR とは、お客様がお持ちのソフトウェアやソリューションが、AWS のベストプラクティスに基づいて実装および運用されているかを、あらかじめ定義されている共通要件に従って検証するパートナープログラムです。すべての要件を満たしてレビューを通過すると、AWS 認定ソフトウェアとして AWS Partner Solutions Finder (PSF) に掲載され、「AWS Qualified Software」ソリューションバッジを利用できるようになります。AWS ファンデーショナルテクニカルレビュー (FTR) とは | AWS JAPAN APN ブログ最初からすべてのベストプラクティスを実装しているワークロードはまずないので、レビューの通過にはワークロードの改善が求められます。首尾よく改善できたら、サービスを実装・運用しているエンジニアの自信になりますし、なによりご利用いただいているお客様の安心にもつながるはずです。また、PSFに掲載されれば、市場認知度の向上も期待できます。まとめENECHANGEは、以上のメリットに期待してAWSパートナーとなりました。AWS認定の新規取得によるクレジット毎年もらえる3,500ドルのクレジットFTRによるワークロードの改善、認知度の向上引用したAWS公式ブログの各記事には、これら以外のメリットも書かれているので、ぜひご参照ください。aws.amazon.comaws.amazon.comAWSパートナーになることを検討される場合は、下記の記事で紹介されている説明会動画をご覧いただくことをお勧めします。aws.amazon.com

メリットだらけなので、AWSパートナーになりました

ENECHANGEの Yuto Ono です。 最近はエンジニアリングマネージャーに任命され、引き続き手を動かして開発しながら、メンバーの育成などにも取り組むようになり、マネジメントの面白さと難しさを実感しています。今回は、前から気になっていた Rails + Hotwire という技術スタックを触ってみたので、それについて書いていきたいと思います。私はフロントエンドが得意分野なのですが、Railsもそれなりに触っているので、Railsでのフロントエンド技術をキャッチアップするのに自分が適任だと思いました（私のフロントエンドの実績は、以前 what we use に寄稿させていただいた記事を見ていただくとわかりやすいかと思います）。whatweuse.dev最近弊社では、 I/O Day という制度を試しに実施しており、エンジニアが1日確保して、通常業務の代わりに技術的なインプット・アウトプットができる制度となっております。今回は、ありがたくその制度を使わせていただきました。キャッチアップするにあたり、こちらのZenn本を参考にさせていただきました。ありがとうございます。zenn.dev技術的な解説はこの本に詳しく書いてあるのでそちらに譲るとして、この記事では、Hotwireを触ってみた感想と、使いどころの考察を書いていきたいと思います。Hotwire を試してみた結果弊社で開発している電気の料金シミュレーションサービス「エネチェンジ」を意識し、電力会社の契約履歴や電気代の請求を管理するサービスをさくっと作ってみました。今回のコードはこちらのリポジトリに上げています。github.com参考記事に書いてあるとおり、Hotwire は Turbo、Stimulus、Strada という3つの技術から構成されています。今回は主に Turbo を活用しています（というか、Turbo しか使えていません…）。Turbo を使うと、ページ遷移することなく画面の一部を更新できるようになり、SPA風の挙動を JavaScript を書かずに実現できます。実際の画面で説明すると、契約履歴管理画面で、画面遷移することなく、履歴を追加したり編集したりできるようになります。 JavaScript を書かずにこれを実現できるのは驚きですよね。「新規追加」をクリックしたときの挙動「編集」をクリックしたときの挙動少しだけ Turbo の仕組み説明をすると、通常の一覧表示の行単位の要素と、入力させるフォームを2つとも turbo_frame_tag というヘルパーで囲みます。<%= turbo_frame_tag contract_history do %>  ...<% end %>該当するコードは下記にあります。app/views/contract_histories/_contract_history.html.erbapp/views/contract_histories/_form.html.erbすると、レンダリング時に <turbo-frame> というカスタム要素になります。<turbo-frame id="contract_history_1" ... >  ...</turbo-frame>そして、このカスタム要素の idを目印に、要素の差し替えをしてくれるという仕組みになっています。ついでに ViewComponent も触ってみた他にも Rails のフロントエンド開発に役立つライブラリで気になっていたものがあるので、ついでに触ってみました。それは ViewComponent というもので、これを使うと、 Rails のビューから呼び出せるコンポーネントを作ることができます。まるで React のように、コンポーネント指向で開発することができる、ということですね。このように、Rubyのクラスと erb を書くことでコンポーネントを宣言できます。class PriceComponent < ViewComponent::Base  def initialize(price:)    @price = price  endend<%= @price.to_i.to_formatted_s(:delimited) %>円app/components/price_component.rbapp/components/price_component.html.erbそして、呼び出す側のビューでこのように書くことで呼び出せます。<%= render(PriceComponent.new(price: 5500)) %>app/views/electricity_bills/_electricity_bill.html.erbこの程度だと正直 helper でも十分な気がしますが、活用できる場面は色々とありそうです。また、今回試せていませんが、Hotwire の構成要素である Stimulus とあわせて使うと、各コンポーネントごとの JavaScript のコードを書けそうだったので、結構色々な使い道がありそうな印象でした。使いどころの考察Rails + Hotwire だけでここまでフロントエンドを作り込めるのはすごいと思いました。Vue や React を導入しなくても、ある程度SPA風の挙動にできるので、 Hotwire で十分というケースは結構多いのではないかという印象を受けました。向いているケース小規模なチーム、特にRailsに慣れている人が多いチームUIに強いこだわりがないプロジェクト人員、時間などのリソースに限りのあるプロジェクト弊社では、Rails経験のあるエンジニアが多く、プロジェクトによっては少数精鋭のチームで開発することもあると思うので、Hotwireを選定する可能性は十分にありそうだなと思いました。向いていないケースフロントエンドエンジニアが確保でき、フロントエンドとバックエンドを分業して進めたい場合リッチなUIを実装したい場合後にSPA化する可能性のあるプロダクト（後からSPA化するのはつらそうなので）toC向けのプロダクトで、リッチなユーザー体験に重きを置くプロダクトだと、Hotwireでは厳しい場面も多いと思います。このような場合は、素直に React や Next.js を使ってSPAとして開発していくのが良さそうですね。感想最近の Rails は、最小限の労力である程度のフロントエンド開発もできるようになっていて、進化が凄まじいなと思いました。今後リリース予定の Rails8 も楽しみです。また、新たな技術を実際に触ってみることで、今後技術選定をする際に実際に触ってみた経験を活かせるので、定期的に技術のキャッチアップをしていくのは大事だなと思いました。今後もプライベートの時間や I/O Day などの施策を活用して新しい技術をインプットしていこうと思います！

Rails + Hotwire を試してみて、使いどころを考えてみた

VPoTの岩本 (iwamot) です。100以上のLLMが使えるSlackbot OSS、Collmboを公開したのでご紹介します。github.com要点：ENECHANGEではChatGPT-in-Slackを便利に使ってきたChatGPT-in-SlackでチャットできるLLMはGPTのみ他のLLMも使えるよう、forkしてLiteLLMを組み込んだENECHANGEではChatGPT-in-Slackを便利に使ってきたENECHANGEでは、LLMとチャットできるSlackbotとしてChatGPT-in-Slackを便利に使ってきました。Slack (Salesforce) のseratchさんが開発されたOSSで、さすがのUXです。github.comSlackbotを社内に公開した2023年5月9日から、もう1年あまりになります。その間、ユーザーとして使うだけではなく、Azure OpenAIのサポートやFunction Callingのサポートなどのコントリビュートもしてきました。ChatGPT-in-SlackでチャットできるLLMはGPTのみただ、ChatGPT-in-SlackでチャットできるLLMは、現時点ではGPTのみです。他のLLMのサポート予定もありません。Claude 3を始め、他のLLMも活発に開発されている状況を考えれば、それらともチャットしてみたいところです。特にClaude 3 Opusは、GPT-4にくらべ高いベンチマーク結果を誇っています。他のLLMとのチャットをChatGPT-in-Slackに遜色ないUXで実現するには、別の手段が必要です。どうすべきでしょうか。他のLLMも使えるよう、forkしてLiteLLMを組み込んだぼくの答えは「ChatGPT-in-SlackをforkしてLiteLLMを組み込む」でした。LiteLLMは、OpenAIと（つまりGPTと）同じインターフェースで100以上のLLMが呼び出せると謳うツールです。GitHubのスター数は9,600を超え、2024年4月のTechnology Radarに掲載されるなど注目を集めています。github.comChatGPT-in-Slackをforkし、OpenAIに依存している箇所をLiteLLMに差し替えられたら、オリジナルと遜色ないUXでGPT以外のLLMも呼び出せそうですよね。ということで、実際に進めて公開したのがCollmboです。github.com名前には「共に育てるLLM bot」の意味を込めました。「コロンボ」とお読みください。ちなみにENECHANGEの社内Slackbotは、すでにこのCollmboに置き換え済みです。狙いどおり、ChatGPT-in-Slackに遜色ないUXを維持できています。ただ、残念ながらLiteLLM側に不具合があるため、Claude 3とのチャットはまだ実現していません。バグレポートは出したので、修正に期待しているところです。まとめ今回は、100以上のLLMが使えるSlackbot OSS、Collmboをご紹介しました。要点：ENECHANGEではChatGPT-in-Slackを便利に使ってきたChatGPT-in-SlackでチャットできるLLMはGPTのみ他のLLMも使えるよう、forkしてLiteLLMを組み込んだまた、本文では触れませんでしたが、Collmboにはカスタムコールバック機能も追加済みです。分析用のログ出力などに活用できます。「共に育てるLLM bot」ということで、気軽にお試し・フィードバックいただけると幸いです。

100以上のLLMが使えるSlackbot OSS、Collmboを公開しました

はじめにJaSST Tohokuについて参加目的セッションについて10:30-12:00 (90分)説明できるテストをつくるためにできることを考える13:50-15:10 (80分)同値分割法と境界値分析15:20-17:10 (110分)クラシフィケーションツリー技法スポンサーライトニングワークスについて終わりにはじめにENECHANGEの工藤です。フルリモートで体が鈍ったので朝活で筋トレを始めたところ、胃の調子がだんだんと良くなってきています。QAと同じで胃も意識すれば品質を上げられると信じております。早速ですが2024年5月31日に仙台で開催されたJaSST'24 Tohokuに参加してきたので、それぞれのセッションの感想およびセッションで取り扱ったテスト技法のポイントについてこの記事で解説できればと思います。また、ENECHAGEではQAのポジションを募集してますので、ご興味おありの方はぜひご応募ください。www.wantedly.comJaSST TohokuについてJaSST（Japan Symposium on Software Testing）は日本各地で開催されている有名なソフトウェアテストシンポジウムです。X（Twitter）では、タグ「#jassttohoku」で、参加者などからの投稿をみれるようになっています。JaSST Tohoku 2024の開催場所は仙台の仙台復興記念館で、タイムテーブル等は以下のURLをご覧ください。jasst.jp参加目的QAエンジニアとして色々な案件に関わっているうちに品質をよりもっと挙げていきたいと強く感じようになってきており、品質をあげるためには何が必要かと自問自答した結果としてイベントに参加して見識を広めたいと思ったからです。また、自分が所属しているエネルギークラウド事業部では社内のQA同士での交流も非常に活発ですが、将来的にはより良い品質のプロダクトを生み出し続けるようになるためにはQA業務のあり方を視座の高い視点で考えて整備していく必要があるとも考えています。セッションについて10:30-12:00 (90分)説明できるテストをつくるためにできることを考える全体的に分かりやすくて、相手に伝わりやすいようにテストとは何かという点に主眼を置いて実際のやりとりの際に生じがちな認識の齟齬の解消を行うことで何をどうしたいのか、具体的に伝えたほうがいいのか、それとも抽象的に伝えた方がいいのか検討をすることは実際の案件でもかなり有効活用できそうだと思いました。また、テスト技法等を使うことでより分かりやすくしたり、説明をしないときでも説明できるような期待結果の書き方を日頃から意識することは大事だなとも感じました。　13:50-15:10 (80分)同値分割法と境界値分析数値の入力欄のフォームをベースに前後の席の方と4人1組になって同値分割法と境界値分析に焦点を当てて、ワークショップを実施しました。午前中に聞いたことを活かしながら、例題について自分の考えとチームの皆さんと議論をしながら認式合わせを行うことができたので、実案件の開発者と認式合わせを行う際にも積極的に使っていこうと思いました。　15:20-17:10 (110分)クラシフィケーションツリー技法普段はあまり聞き慣れないクラシフィケーションツリー技法について解説を聞きながら、実際に自分たちで大きめの方眼用紙に付箋を貼り付けて書き込みを実施しました。例題はとあるECサイトのランク別の配送料についてのものでしたが、エイヤのノリで作ったら途中で思ったのと違ったので作り直しましたが、作り直したことによってシンプルで分かりやすいツリーにすることが出来て良かったです。スポンサーライトニングワークスについて午後の初めとクロージングセッション手前にありましたが、どの会社様も品質を高めるためにQAエンジニアの育成をどうしたのか、ツールをどうやって使っているのか、もしくは内製化を目指すのかといったそれぞれの観点で解決策を提示されていて非常に勉強になりました。その中でも代表的なものを掲載させていただきます。www.docswell.com終わりに普段から勉強会にはそれとなく参加していましたが、オフライン開催のみの勉強会にでたのは初めてだったので移動も含めて非常に新鮮でした。（仙台のホテルがポケモンのイベントのために取れずに、朝4時起きの深夜12時帰宅だったのは内緒）今回学んだことを社内業務に活かして、現在取り組んでいる自動化についても内容を研磨していきチームにもいい影響を与えることができればいいなと思います。最後になりますが、ENECHANGEではQAエンジニアを募集していますのでぜひご応募ください。www.wantedly.com

JaSST'24 Tohokuに参加してきました！〜テスト技法編〜

ENECHANGEの園木です。本記事では、一部のセッションの内容やRuby会議の様子をお届けします。参加したセッションを一部紹介Let's use LLMs from Ruby 〜 Refine RBS types using LLM 〜近年急激に性能を向上しているLLMを活用し、Rubyの型推測をおこなうチャレンジについて発表してくださいました。スピーカーさんの記事RubyKaigi 2024 で RBS と LLM の話をしましたExploring Reline: Enhancing Command Line UsabilityRelineとGNU Readlineの違いを紹介したうえで、Relineにundo機能を追加したという内容を発表してくださいました。Getting along with YAML comments with Psychyamlファイル内に#を使ってコメントを記載するためにPsych-commentsというgemを作成したという内容を紹介してくださいました。どのような流れかというと、、目的の共有（こういうことを実現したい）成果物の提示（成果物はこちらです）前提（そもそもxxというのは、、、）アプローチ（だから、このようなアプローチをしました）実装中に発生した壁（すると、新たにこんな問題が発生しました）アプローチ_2（それをこのようにして乗り越えました）成果物のデモ（その結果できあがったのがこちらです）（今後の課題）締め課題と結論を最初に提示することで、コアな部分を理解できなくてもセッションの全体像を掴むことができます。登壇資料Getting along with YAML comments with Psych - Speaker DeckMatz Keynote今回のRubyKaigiでは、まつもとゆきひろ氏のキーノートは最後におこなわれました。MatzはRubyに対して、以下の理由でGoodと表現していました。「こういうメソッドがあったら良いのにな」が大体ある制限が少ないさまざまな企業で採用されている（参考）昔と比べて効率がよいコミュニティが活発そんなRubyをGreatにするためには、何よりもパフォーマンスの向上が必要であることを伝えていました。コミッターさんやスピーカーさんとも会話をすることができました単身で乗り込んだRubyKaigiを最大限に楽しむために、たくさんの方に声をかけさせて頂きました。コミッターとしてのモチベーションや、海外でのRuby事情、各企業の文化などを聞くことができました。特に印象的だったのは、Shopifyさんが壇上で話していた以下のことです。Shopifyは100年続く企業を目指しているShopifyはRubyで作られているつまり、Rubyの発展はShopifyの発展だ自分が気持ちよくRubyで開発できているのも、コミッターさんがRubyを改善してくださったり、スピーカーさんが新しい使い方を提示してくださるからなんだなぁとしみじみと感じました。毎日がお祭り騒ぎ会場にはRubyを採用している企業のブースが並んでいました。会期中は毎日がお祭りのようでした。また、会期中は毎晩Rubyを採用している企業がイベントを主催してくださっていました。次回開催閉会式では、次回開催情報も発表されました。日時: 2025年4月16日-18日場所: 愛媛県松山市来年も私は行きたい気持ちがありますので、本記事を読んだ方は現地でお話できたら嬉しいです！以上でRubyKaigi 2024のレポートを終わりにしたいと思います。ENECHANGEではRubyエンジニアを募集しています！弊社はエネルギーの未来をつくるというミッションを掲げています。www.wantedly.com

RubyKaigi 2024 に参加してきました！

概要最近、最新のアクションカメラを購入してYoutube用に動画編集してるCTO室のKazです今回、MySQLのマイグレーション時、Index有効クエリを高速化するため、ボトルネックを特定してそれを解消しました。結果Index有効化において適切なメモリ量を確保し、MySQL Workbenchのパフォーマンスレポートを確認することで、システムのボトルネックを特定しました。その結果、プロビジョニングIOPSを利用することにより、特に時間を要していたテーブルのインデックス有効化の時間を大幅に短縮し、システム全体の効率化を図ることができました。インデックス有効化の実行時間の比較 項目                            時間                          プロビジョニングIOPS利用前     約178.94分                   プロビジョニングIOPS利用後     約74.3分                     時間の短縮量                   約104.64分                   短縮率                         約58.5%                     Import先DB 項目                 詳細                                       インスタンスクラス    db.m7g.2xlarge                             vCPU                 8                                          RAM                  32GB                                       ストレージタイプ      汎用 SSD (gp2)                             ストレージ            198 GiB  （最大IOPSは9900）                      プロビジョンド IOPS  5000 (測定値の最大値近くを設定)            プロビジョンド IOPS：5000インスタンスクラス：db.m7g.2xlarge- 総合的に考えると、最低でも24 GB以上のメモリが必要でした。Info 監視ツールで80%のメモリ使用率が可視化されているとしても、それはバッファプールに割り当てられたメモリの量を反映しています。実際に必要なメモリ量は、バッファプール内のデータアクセスパターンによって異なるため、常に80%のメモリがアクティブに使用されているわけではありません。MySQLのメモリ使用状況を確認MySQLのメモリ使用状況を確認SHOW ENGINE INNODB STATUS;SHOW ENGINE INNODB STATUS コマンドの出力の一部----------------------BUFFER POOL AND MEMORY----------------------Total large memory allocated 2745958400Dictionary memory allocated 2122468Buffer pool size   163840Free buffers       8205Database pages     155340Old database pages 57179Modified db pages  0Pending reads      0Pending writes: LRU 0, flush list 0, single page 0Pages made young 3056426, not young 1848894540.00 youngs/s, 0.00 non-youngs/sPages read 12983565, created 620638, written 373918700.00 reads/s, 0.00 creates/s, 0.00 writes/sNo buffer pool page gets since the last printoutPages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/sLRU len: 155340, unzip_LRU len: 0I/O sum[96]:cur[0], unzip sum[0]:cur[0]Total large memory allocated: 2745958400 bytes (約2.56 GB)Dictionary memory allocated: 2122468 bytes (約2 MB)Buffer pool size: 163840 pages (1ページ = 16 KB, 約2.56 GB)Free buffers: 8205 pagesDatabase pages: 155340 pagesOld database pages: 57179 pagesModified db pages: 0Pending reads: 0Pending writes: LRU 0, flush list 0, single page 0SHOW ENGINE INNODB STATUSからメモリ使用量の計算バッファプール全体のメモリ量: Total large memory allocated約2.56 GBディクショナリメモリを引く: Dictionary memory allocated約2.12 MBバッファプールが使用しているメモリ量:約2.56 GB - 約2.12 MB = 約2.56 GB（innodb_buffer_pool_sizeは{DBInstanceClassMemory*3/4}と推奨の値になっているので一致）メモリ使用量の見積もりSELECT     table_schema AS 'Database',     ROUND(SUM(data_length) / 1024 / 1024, 2) AS 'Data Size (MB)',     ROUND(SUM(index_length) / 1024 / 1024, 2) AS 'Index Size (MB)',     ROUND(SUM(data_length + index_length) / 1024 / 1024, 2) AS 'Total Size (MB)'FROM     information_schema.tables WHERE     table_schema = '<schema>' GROUP BY     table_schema; Database   Data Size (MB)  Index Size (MB)  Total Size (MB)    5746.02          13400.30         19146.31        データベースの現状データサイズ: 約5.75 GBインデックスサイズ: 約13.4 GB合計サイズ: 約19.15 GBInnoDBバッファプールのサイズ現在のバッファプールサイズ: 約2.56 GB（163,840ページ、1ページ16 KB）現在のメモリ使用状況バッファプールが使用されているメモリ量: 約2.37 GB必要なメモリ量の見積もり基本的には、データサイズとインデックスサイズの合計量に加え、ある程度のバッファやシステムのオーバーヘッドを考慮してメモリを割り当てることが推奨されます。以下に、計算手順を示します：データとインデックスの合計サイズ約19.15 GBバッファプールのサイズ一般的には、データとインデックスの合計サイズの80%～100%程度のバッファプールサイズを設定19.15 GBの80%は約15.32 GBシステムのオーバーヘッドMySQLサーバやOS自体が必要とするメモリも考慮する必要があるので通常、4 GB程度とする推奨メモリ量総合的に考えると、データベースサーバに最低でも24 GB以上のメモリが必要。最小メモリ量: 約24 GB（15.32 GBのバッファプール + 4 GBのオーバーヘッド + 追加の余裕）推奨メモリ量: 32 GB（19.15 GBのバッファプール + 4 GBのオーバーヘッド + 追加の余裕）Exportストアドプロシージャとストアドファンクションを除外せず、データベース全体の完全なバックアップを作成するデータベースマイグレーション時にストアドプロシージャやストアドファンクションを含めた完全なバックアップを作成することは、アプリケーションの機能維持、データ整合性の確保において重要です。index無効化export時はIndexサイズが大きいテーブルにおいてIndex無効化しておく。インデックスサイズが大きいものを無効化するというアプローチは合理的だが無効化によってデータの整合性が失われるリスクに注意する。index無効化対象テーブル Table  Table Size (MB)  Data Size (MB)  ndex Size (MB)  Table_A  16891.77  4311.00  12580.77  Table_B  998.81  424.94  573.88  Table_C  328.33  155.67  172.66  Table_D  136.25  118.67  17.58 テーブルが持つインデックスサイズを知る(top10)SELECT     table_schema AS `Database`,     table_name AS `Table`,     ROUND(SUM(index_length) / 1024 / 1024, 2) AS `Index Size (MB)`FROM     information_schema.tablesWHERE     table_schema NOT IN ('information_schema', 'mysql', 'performance_schema', 'sys')GROUP BY     table_schema, table_nameORDER BY     `Index Size (MB)` DESCLIMIT     10;テーブルが持つインデックスサイズを知るSELECT    TABLE_NAME,    INDEX_NAME,    SEQ_IN_INDEX,    COLUMN_NAMEFROM    INFORMATION_SCHEMA.STATISTICSWHERE    TABLE_SCHEMA = '<database_name>'    AND TABLE_NAME = 'Table_A'ORDER BY    INDEX_NAME, SEQ_IN_INDEX;Index無効化use <database_name>;ALTER TABLE Table_A DROP INDEX <index_name>;Export commandmysqldump --host=<hostname> --port=3306 --default-character-set=utf8 --user=<username> --password --protocol=tcp --routines <schema> > C:\Users\Administrator\Documents\dumps\<schema>_full_backup.sql--routinesストアドプロシージャとファンクションのエクスポートこのオプションを使用することで、MySQLデータベースからストアドプロシージャとストアドファンクションを含めたエクスポートが可能です。所要時間約120分ImportImport先DB指定したschemaがDBに存在しない場合はエラーになるのでschemaは事前に作っておくCREATE SCHEMA `<schema>` ;mysql --host=<hostname> --port=3306 --default-character-set=utf8 --user=<username> --password --protocol=tcp <schema> < C:\Users\Administrator\Documents\dumps\<schema>_full_backup.sql所要時間約60分Index有効化インデックス有効化とプロビジョニングIOPSの関係データベースのインデックスを有効化する際に、プロビジョニングIOPSを利用していなかった場合、クエリの実行に長時間が必要です。これは、インデックスの作成や更新には多くのディスクI/Oが必要となり、ディスクアクセスがボトルネックになるためです。具体的には、以下のような状況が発生しました。状況: インデックスの有効化を行うクエリの実行中、ディスクI/Oの負荷が高まり、IOPS（Input/Output Operations Per Second）の制限に達しました。(gp2のバースト性能の上限は、3,000 IOPS)結果、クエリの実行時間が長くなり、データベースの応答性が低下しました。ボトルネック解消の打ち手プロビジョニングIOPSを使用したEBSに変更することで、以下の利点が期待できます。高いI/Oキャパシティ: プロビジョニングIOPS EBSボリュームは、予測可能かつ高いI/Oパフォーマンスを提供します。これにより、データベースの書き込み操作が迅速に行われ、ボトルネックが解消される可能性が高くなります。低レイテンシ:プロビジョニングIOPSは低レイテンシを提供するため、データの読み書き速度が向上し、インポート時間が短縮されます。一般的な用途でOKなio1を選択するindex有効化実行無効化しているテーブルに対してIndexを有効化します。use <schema>;ALTER TABLE <table_name> ADD INDEX <index_name> (colum1, colum2, colum3, colum4);インデックス有効化の時間と効果プロビジョニングIOPSを利用することで、一番時間を要していたテーブルのインデックス有効化の時間が大幅に短縮され、効率化が図られました。 項目                  時間                実行時間             約63分              時間の短縮量         約47.4分            短縮率               約75.3%            05:35:56  ALTER TABLE <table_name> ADD INDEX <index_name> (column1, column2, column3, column4)    0 row(s) affected Records: 0  Duplicates: 0  Warnings: 0  933.094 sec 項目                                    プロビジョニングIOPS利用前  プロビジョニングIOPS利用後  インデックス有効化にかかる時間          約63分                      約15.6分                    時間の短縮量                           -                           約47.4分                    短縮率                                 -                           約75.3%                     実行前、後の効果                       -                           大幅に短縮され、効率化     補足これらのパラメータを設定することで、接続が長時間アイドル状態になるのを防ぎ、サーバのリソースを効果的に管理することができます。RDStimeoutしないようにしておく パラメータ           説明                                                                                                                  設定値       interactive_timeout  このパラメータは、MySQLサーバがインタラクティブクライアント（通常はMySQLコンソールなどの手動入力が行われるセッション）に対してどれくらいの時間アイドル状態を許可するかを指定します。このタイムアウト時間が経過すると、サーバは接続を閉じます。  3600秒  wait_timeout        このパラメータは、MySQLサーバが非インタラクティブクライアント（アプリケーションやスクリプトなどの自動接続）に対してどれくらいの時間アイドル状態を許可するかを指定します。このタイムアウト時間が経過すると、サーバは接続を閉じます。  28800秒 MySQL Workbenchtimeoutしないようにしておくボトルネック調査で推奨されるレポートHot Spots for I/O:Top File I/O Activity Report: どのファイルが最もI/Oを引き起こしているかを確認します。Top I/O by File by Time: 時間ごとのファイルI/Oを確認します。Top I/O by Event Category: イベントカテゴリ別のI/Oを確認します。Top I/O by Time by Event Categories: イベントカテゴリごとの時間別I/Oを確認します。Top I/O Time by User/Thread: ユーザーやスレッドごとのI/O時間を確認します。High Cost SQL Statements:Statements in Highest 5 Percent by Runtime: 実行時間が最も長い上位5%のSQLステートメントを確認します。With Sorting: ソートを伴うクエリを確認します。Full Table Scans: フルテーブルスキャンを行っているクエリを確認します。Database Schema Statistics:Schema Index Statistics: インデックスの統計情報を確認します。Schema Table Statistics: テーブルの統計情報を確認します。Tables with Full Table Scans: フルテーブルスキャンを行っているテーブルを確認します。Unused Indexes: 使用されていないインデックスを確認します。Wait Event Times (Expert):Global Waits by Time: 全体の待機時間を確認します。Waits by User by Time: ユーザーごとの待機時間を確認します。Wait Classes by Time: 待機クラスごとの待機時間を確認します。Wait Classes by Average Time: 平均待機時間ごとの待機クラスを確認します。InnoDB Statistics:InnoDB Buffer Stats by Schema: スキーマごとのInnoDBバッファの統計を確認します。InnoDB Buffer Stats by Table: テーブルごとのInnoDBバッファの統計を確認します。User Resource Use:Overview: ユーザーごとのリソース使用状況を確認します。I/O Statistics: I/O統計情報を確認します。Statement Statistics: ステートメントの統計情報を確認します。

MySQLパフォーマンス向上のためのプロビジョニングIOPSの活用とその結果

こんにちは、ENECHANGE株式会社でVPoTを務めている岩本 (iwamot) です。このブログの人気記事ランキングをSlackに自動投稿するよう実装したので、事例としてご紹介します。Google Analytics 4 (GA4) のレポートを見に行かなくても、どんな記事が読まれているのか手軽に確認できて便利です。実装方法はいろいろ考えられますが、今回選んだのは下記でした。Amazon AppFlowを使い、GA4データをAmazon S3に保存保存をトリガーにAWS Lambda関数を呼び出し、データを加工してSlackに投稿以下、AppFlowを中心に詳しくご説明します。SaaSとAWSのデータ連携が自動化できるAmazon AppFlowAppFlowは、SaaSとAWSサービス間のデータ連携を自動化できるサービスです。たとえば、Salesforce・SAP・Google Analyticsなどのデータを、Redshift・S3などに連携できます。左側のSaaSから、右側のAWSサービスへ、AppFlowでデータ連携できる（画像引用元：https://aws.amazon.com/jp/appflow/）ENECHANGEでは、ほとんどのワークロードをAWSで運用しているので、人気記事ランキングの自動投稿もAWSで運用したいところです。そこで、AppFlowを使って、GA4のデータをS3に保存することにしました。事前準備：AppFlowとGA4の接続を作成AppFlowでGA4のデータをS3に保存するには、まず接続を作成する必要があります。ぼくは、AWSのドキュメントや、クラスメソッドさんの記事を参考に進めました。docs.aws.amazon.comdev.classmethod.jpAppFlowのフローを作成続いて、AppFlowのフローを作成します。こちらは、AWSのソリューションアーキテクト・はまーんさんの記事を参考に進めました。track3jyo.com具体的な設定は下記の通りです。送信元の設定送信元として、GA4の接続やオブジェクトを選びます。送信先の設定送信先として、S3バケットを選びます。ファイル形式はCSVにしました。デフォルトのJSON Linesデータより、今回のLambda関数では処理しやすいためです。フロートリガーの設定フロートリガーは月曜10時としました。転送モードを増分転送にしたのは、週間ランキングを投稿したいからです。完全転送だと月間（30日）ランキングになります。フィールドマッピングの設定フィールドマッピングでは下記を指定しました。customEvent:post_date（投稿日。はてなブログ独自のカスタムディメンション）screenPageViews（ページビュー数）unifiedPagePathScreen（URLのパス。例：/entry/2022/10/25/100000）unifiedScreenName（記事名）これで下記のようなCSVが得られます。"unifiedScreenName","unifiedPagePathScreen","screenPageViews","customEvent:post_date""DockerfileでのENTRYPOINTとCMDの関係を整理する 〜 2つの記述形式に環境変数展開とシェル引数展開を添えて 〜 - ENECHANGE Developer Blog","/entry/2022/10/25/100000","40","2022-10-25"パーティションと集約の設定パーティションの設定は「毎日」としました。S3のフォルダパスを見るだけで、何年何月何日に作られたデータか分かるからです。集約の設定は、1ファイルとしました。複数ファイルだと、Lambdaで処理しづらくなります。フィルターの設定フィルターは下記の2件を設定しました。unifiedPagePathScreen が次を含む /entry/（記事ページのみに絞りたい）unifiedScreenName が次を含む - ENECHANGE Developer Blog（翻訳されたアクセスは無視したい）Lambda関数を作成あとは、S3保存をトリガーとするLambda関数を作るだけです。データ加工と、Slack投稿を担当します。はまーんさんの記事ではデータ加工にAWS Glue DataBrewを使っていますが、今回のようにLambda関数でSlackに投稿するのであれば、加工も同じ関数に任せるのがシンプルだと判断しました。ChatGPTに相談しながら最終的にできたのが下記のコードです。import csvimport ioimport jsonimport osimport urllib.parseimport urllib.requestimport boto3base_url = "https://tech.enechange.co.jp"slack_webhook_url = os.environ["SLACK_WEBHOOK_URL"]s3 = boto3.client("s3")def lambda_handler(event, context):    # S3のCSVデータを取得する    bucket = event["Records"][0]["s3"]["bucket"]["name"]    key = urllib.parse.unquote_plus(        event["Records"][0]["s3"]["object"]["key"], encoding="utf-8"    )    response = s3.get_object(Bucket=bucket, Key=key)    body = response["Body"].read().decode("utf-8")    csv_string = io.StringIO(body)    reader = csv.reader(csv_string)    # ヘッダを読み飛ばす    _ = next(reader)    # ページビュー数の降順でソートする    data_rows = [row for row in reader]    sorted_data = sorted(data_rows, key=lambda x: int(x[2]), reverse=True)    # 上位10件のデータで投稿メッセージを組み立てる    message_lines = []    for i, row in enumerate(sorted_data[:10]):        # 記事名からブログ名を削除する        title = row[0].replace(" - ENECHANGE Developer Blog", "")        # URLを「https://」からに整える        url = f"{base_url}{row[1]}"        # メッセージに行を追加する        page_views = row[2]        post_date = row[3]        line = f"*{post_date}* <{url}|{title}> {page_views} views"        message_lines.append(line)    # メッセージを整えてSlackに投稿する    header = "ENECHANGE Developer Blogの先週の人気記事です :medetai-nya:"    message = header + "\n\n" + "\n".join(message_lines)    data = json.dumps({"text": message}).encode("utf-8")    req = urllib.request.Request(        slack_webhook_url, data, headers={"Content-Type": "application/json"}    )    urllib.request.urlopen(req)    return {        "statusCode": 200,        "body": "OK",    }これで毎週月曜10時に、人気記事ランキングが投稿されるようになりました。おわりにAppFlowでGA4のデータをS3に保存し、Lambdaで加工してSlackに投稿する例をご紹介しました。今回は人気記事ランキングでしたが、各種コンバージョンの分析結果も簡単に投稿できるはずです。GA4に限らず、SaaSのデータをAWSで処理したいときには、AppFlowの活用をお勧めします。接続できるSaaSは、AWSのドキュメントでご確認ください。docs.aws.amazon.com

Amazon AppFlowをGA4に接続し、人気記事ランキングをSlackに自動投稿する

Wi−Fiネットワーク調査報告カスタマーサービスセンターの新拠点におけるネットワークを調査し、スケジュール遅滞なく業務を開始できることを目的としました。新拠点では既存の通信速度と安定性を担保する必要があり、特にインターネット接続とAWSに構築しているVerified Accessの品質を確認しました。これにより、現行のネットワーク基準を満たし、業務のスムーズな移行と運用が可能であることを確認しました。運用しているVerified Accessについて説明従来のVPN接続で発生する待機時間や、VPNクライアントのアップデート、設定変更といった追加の手間が不要になります。これにより、ユーザーはよりスムーズにセキュアな接続を確立できるため、AWS Verified Accessを採用しています。これにより、運用の効率化とセキュリティの向上が実現できます。Verified Access Instance:Verified Accessの管理とポリシー設定の中心。全体的なアクセス制御とポリシーを管理します。Verified Access Trust Providers:ユーザーの認証と信頼性の確認を担当。外部IDプロバイダーや他の信頼ソースと連携。Azure Entra ID:Verified Access Trust Providersの一部として機能。ユーザー認証およびアクセス管理に使用され、MicrosoftのID管理ソリューションと統合。Verified Access Groups:同じアクセス要件を持つユーザーやデバイスをグループ化。アクセス管理の単位として機能。Route 53 (DNS):DNSサービスを提供し、Verified Accessエンドポイントの名前解決をサポート。Verified Accessエンドポイントへのアクセスを簡素化し、冗長性と可用性を向上。Verified Access Endpoints:ユーザーがアクセスするための具体的なエントリーポイント。アクセスされるリソースやサービスを指定。Users:Verified Access Endpointsに接続するユーザー。Azure Entra IDを使用して認証され、アクセスが許可されます。                     +----------------------------------------------------+                     |                  Verified Access                   |                     |                      Instance                      |                     +----------------------------------------------------+                                     /|\              /|\                                      |                |                                      |                |                    +-----------------+                +-----------------+                    |                                                      |     +--------------+-----------------+            +-----------------------+----------------+     | Verified Access trust providers |            |     Verified Access groups             |     +--------------+-----------------+            +-----------------------+----------------+                    |                                                      |                    |                                                      |                    |                                                      | +------------------+-----------+                           +--------------+-----------------+ |  Azure Entra ID (Azure AD)   |                           |      Route 53 (DNS)           | +------------------------------+                           +--------------+-----------------+                    |                                                      |                    +-----------------+                +-------------------+                                      |                |                                      |                |                                     \|/              \|/                     +----------------------------------------------------+                     |                    Verified Access                  |                     |                       endpoints                     |                     +----------------------------------------------------+                                     /|\                                      |                                      |                                     \|/                              +----------------+                              |      Users      |                              +----------------+評価要素スピード接続安定性ネットワークキャパシティテスト方法ツール: speedtest-cli、iperf、pingを使用してインターネット速度とネットワーク品質を測定。プロセス:speedtest-cliを実行してダウンロード速度、アップロード速度、レイテンシを測定。                    +------------------------+                    |       ローカルネットワーク   |                    |        クライアント        |                    +------------------------+                               |                               | インターネット経由                               |                    +------------------------+                    |      インターネット         |                    |    speedtestサーバ      |                    +------------------------+iperfを使用してアップロード速度を測定し、特にAWS内のVerified Accessの品質を確認。                    +------------------------+                    |       ローカルネットワーク   |                    |        クライアント        |                    +------------------------+                               |                               | インターネット経由                               |                    +------------------------+                    |          AWS           |                    |       iperfサーバ       |                    +------------------------+pingを使用してGoogle DNSサーバー（8.8.8.8）への接続性とレイテンシを測定。                    +------------------------+                    |       ローカルネットワーク   |                    |        クライアント        |                    +------------------------+                               |                               | インターネット経由                               |                    +------------------------+                    |      インターネット         |                    |    Google DNSサーバ      |                    +------------------------+テスト場所Wi-Fi機器を部屋の中心に地上高1.5mに配置し、一番近い場所と遠い場所で計測しました。使用した周波数は2.4GHzで部屋の内部にはパーティションなどの障害物はありません。結果場所によってネットワーク速度に大きな差が見られるため、WiFi機器を増やすなどの対策を検討し、ネットワークのカバレッジと安定性を向上させる必要がありました。近い場所での計測結果ダウンロード速度測定値: 163.50 Mbit/s評価: 非常に高速。大容量のファイルのダウンロードや高解像度のストリーミングに適しており、一般的なインターネットアクティビティに対して優れた性能を提供します。アップロード速度測定値: speedtest-cliでは375.96 Mbit/s、iperfでは275 Mbit/s評価: 非常に高速。クラウドストレージへの大容量ファイルのアップロード、ビデオ会議、ライブストリーミングなどに対して優れた性能を提供します。レイテンシspeedtest-cli: 10.876 msping: 平均8.523 ms（最小5.047 ms、最大15.605 ms、標準偏差2.335 ms）評価: 低レイテンシ。オンラインゲームやビデオ会議などのリアルタイムアプリケーションにおいて、非常に快適な使用感が期待できます。パケットロス測定値: 0.0%評価: 非常に安定した接続。データの損失がないため、信頼性の高いネットワーク接続が提供されています。遠い場所での計測結果ダウンロード速度測定値: 12.27 Mbit/s評価: 一般的なWebブラウジングや標準画質の動画ストリーミングには十分ですが、大容量のファイルダウンロードや高画質ストリーミングにはやや遅いと感じるかもしれません。アップロード速度測定値: speedtest-cliでは88.60 Mbit/s、iperfでは140 Mbit/s評価: 比較的高速なアップロード速度。クラウドストレージへのファイルのアップロードやビデオ会議には十分な性能を提供します。レイテンシspeedtest-cli: 66.487 msping: 平均43.817 ms（最小9.416 ms、最大783.431 ms、標準偏差113.130 ms）評価: ピン値の平均と最大値が高く、標準偏差も大きいため、リアルタイムアプリケーション（オンラインゲームやビデオ会議）では不安定さを感じる可能性があります。パケットロス測定値: 0.0%評価: パケットロスがないため、データの損失がないことを示しており、安定した接続が提供されています。反省点複数回のテストを行い、それぞれの計測値で最も高い値と最も低い値を除外したトリム平均（トリムメディアン）を使用して、より信頼性の高い速度評価を行うべきでした。

カスタマーサービスセンターの新拠点のネットワーク調査

こんにちは、2023年7月からコツコツ集めて現在72WLD所有しているCTO室のkazです。OpenAI Whisperを試してみたOpenAIが開発した音声認識モデルWhisperを使用して、実際の音声データをテキストに変換してみました。その結果、非常に高い精度で音声を文字起こしできることが確認できました。具体的には、Google ColaboratoryでGoogleドライブをマウントし、マウントしたディレクトリにある音声データをWhisperを使用してテキストデータに変換します。生成されたテキストデータをChatGPTで要約し、議事録を作成します。OpenAI Whisper についてOpenAI Whisperは、OpenAIによって開発された音声認識モデルです。以下にWhisperの概要と特徴について簡単に説明します。OpenAI Whisper概要Whisper は、音声データをテキストに変換するための高度な音声認識モデルです。様々な言語やドメインの音声データを処理する能力があります。高い精度で音声から文字起こしを行い、多様なアクセントや方言にも対応できます。特徴高精度な認識:Whisperは、大量の音声データで訓練されており、高い認識精度を誇ります。ノイズやバックグラウンド音がある環境でも良好なパフォーマンスを発揮します。多言語対応:Whisperは、英語だけでなく、多くの言語をサポートしています。多言語間の音声認識が可能で、国際的なアプリケーションにも適しています。アクセントと方言の認識:様々なアクセントや方言に対応しており、異なる地域の音声データも正確に認識します。リアルタイム処理:Whisperはリアルタイムでの音声認識をサポートしており、ライブイベントやストリーミングアプリケーションでの利用が可能です。使いやすさ:OpenAIが提供するAPIを通じて、簡単にWhisperを統合することができます。開発者は、音声データをAPIに送信するだけで、テキストに変換された結果を受け取ることができます。使用例字幕生成:映画や動画の自動字幕生成に利用できます。音声コマンド:スマートデバイスやアプリケーションに音声コマンド機能を追加できます。音声検索:音声による検索クエリの処理に利用できます。カスタマーサービス:カスタマーサポートの音声応答システムに統合し、顧客の問い合わせを自動処理できます。Google Colaboratory についてGoogle Colaboratory（略してGoogle Colab）は、Googleが提供する無料のクラウドベースのJupyterノートブック環境です。データサイエンス、機械学習、ディープラーニングのプロジェクトに特化しており、Pythonコードの記述と実行を簡単に行うことができます。Google Colaboratory概要クラウドベース: インストール不要で、ブラウザ上で直接使用可能。無料のGPUサポート: 高性能なハードウェア（GPU、TPU）を無料で利用可能。Python環境: データサイエンスや機械学習に最適化されたPython環境を提供。共有とコラボレーション: ノートブックを他のユーザーと簡単に共有し、共同編集が可能。特徴インストール不要:ブラウザ上で動作するため、ソフトウェアのインストールや設定が不要です。高性能なハードウェア:無料でGPUやTPUを使用でき、大規模なデータ処理や機械学習モデルのトレーニングが可能です。Pythonと統合:データサイエンスや機械学習で広く使用されているPythonライブラリ（NumPy、Pandas、TensorFlow、PyTorchなど）をサポートしています。シームレスな共有:Googleドライブと統合されており、ノートブックを他のユーザーと簡単に共有できます。共同編集も可能です。セルベースのコード実行:Jupyterノートブック形式を採用しており、セルごとにコードを実行し、結果をすぐに確認できます。使用例データサイエンス:データの前処理、可視化、解析を簡単に行えます。機械学習:モデルの構築、トレーニング、評価を行うための理想的な環境です。教育:プログラミングやデータサイエンスの教育ツールとして利用できます。ChatGPT についてChatGPTは、OpenAIによって開発された高度な対話型AIモデルです。GPT（Generative Pre-trained Transformer）アーキテクチャに基づいており、人間のような自然な対話を行うことができます。ChatGPT概要開発元: OpenAIアーキテクチャ: GPT（Generative Pre-trained Transformer）目的: 自然言語処理と生成に特化し、様々な対話型アプリケーションに利用されます。特徴自然な対話:人間のように自然な文章を生成し、流暢な対話が可能です。多用途:カスタマーサポート、教育、エンターテインメントなど、様々な分野で利用されています。高度な理解能力:文脈を理解し、適切な応答を生成する能力があります。継続的な学習:大量のテキストデータを基に訓練されており、定期的にアップデートされることで、最新の知識を反映しています。使用例カスタマーサポート:顧客からの問い合わせに自動で応答し、問題解決を支援します。パーソナルアシスタント:スケジュール管理、リマインダー設定、情報提供など、日常生活をサポートします。教育:学習支援ツールとして、学生の質問に答えたり、学習資料を提供します。エンターテインメント:対話型ゲームやストーリーテリングに利用され、ユーザーにインタラクティブな体験を提供します。手順WhisperOpenAIでAPIキーを作成します。Google Colaboratoryノートブックを新規作成します。「ハードウェアアクセラレータ」をGPUに変更する「ハードウェアアクセラレータ」をGPUに変更する主な理由Google Colaboratoryで「ハードウェアアクセラレータ」をGPUに変更する主な理由は、計算速度の向上、モデルのトレーニング時間の短縮、高精度なモデルの効率的な訓練です。これにより、特にディープラーニングや大規模なデータセットを扱うタスクにおいて、開発効率が大幅に向上します。OpenAIのAPIキーを登録するためにコードを実行します。ColabAIを使用すればプログラムの知識が無くてもなんとかなりますね。Googleドライブをマウントしますとりあえず、音声データを指定してテキストデータに変換します。OpenAIのWhisperモデルの各バリエーション（tiny、base、small、medium、large）が用意されています。これらのモデルは、音声認識性能と計算リソースのトレードオフが異なります。Whisperモデルのバリエーションと特徴Whisperモデルのバリエーションと特徴モデルの種類Whisperモデルは、以下のように複数のサイズがあり、それぞれ性能と計算リソースのバランスが異なります。1. Tinyパラメータ数: 約39Mモデルサイズ: 約72MB推論速度: 非常に高速特徴: 最小サイズのモデルであり、計算資源の少ない環境やリアルタイム処理が求められるアプリケーションに適しています。音声認識の精度は他の大きなモデルに比べてやや低いですが、十分な性能を発揮します。2. Baseパラメータ数: 約74Mモデルサイズ: 約140MB推論速度: 高速特徴: Tinyモデルよりも精度が高く、依然として高速な推論を提供します。計算資源が限られているが、精度がより求められる場合に適しています。3. Smallパラメータ数: 約244Mモデルサイズ: 約466MB推論速度: 中速特徴: ベースモデルよりもさらに高い精度を提供し、一般的な用途での音声認識に非常に適しています。計算資源と精度のバランスが良いモデルです。4. Mediumパラメータ数: 約769Mモデルサイズ: 約1.5GB推論速度: 低速特徴: 小規模なモデルよりも高い精度を持ち、大規模なデータセットや高精度が求められるタスクに適しています。計算資源が豊富にある環境で使用するのが理想的です。5. Largeパラメータ数: 約1550Mモデルサイズ: 約3GB推論速度: 非常に低速特徴: 最高の精度を提供し、大規模なデータセットや最高の認識精度が求められるプロジェクトに適しています。計算リソースを大量に消費するため、性能重視の環境での使用が推奨されます。選択のポイント計算資源: リアルタイム処理や低リソース環境では、TinyやBaseモデルが適しています。認識精度: 高い精度が求められる場合は、Small、Medium、Largeモデルを選択します。推論速度: 推論速度が重要な場合は、TinyまたはBaseモデルを選択します。この程度のデータなら誤字はありませんね。3時のNHKニュースです。消防によりますと、きょう昼過ぎ、熊本県阿蘇市黒川の山中に、遊覧ヘリコプターが不自着したということです。処理が終わったらGoogleドライブをアンマウントしますテキストデータにした会議内容をChatGPTに要約させる（実際の録音データだともっとノイズが入りますが適切なモデルを使用すれば精度は高いです）今日は明日の天気予報の公表方法について議論したいと思います。まず、佐藤さんから明日の天気予報の概要を教えてください。はい、明日の天気は全国的に晴れですが、一部地域で午後から雨が降る予報が出ています。特に北部では雷を伴う激しい雨になる可能性があります。気温は平均して25度前後です。ありがとうございます。では、鈴木さん、今回の天気予報をどうやって公表する予定ですか？そうですね、まずは公式ウェブサイトに詳細な予報を掲載し、その後、SNSやメルマガを通じて速報を流す予定です。特に激しい雨の地域については、注意喚起を強調したいと思います。なるほど。では、山田さん、SNSでの公表についてご意見をお願いします。はい、SNSではインフォグラフィックを使って視覚的にわかりやすい形で情報を発信しようと考えています。また、リアルタイムで更新されるストーリーズも活用して、最新の情報をタイムリーに届ける予定です。それはいいですね。小林さん、インフォグラフィックのデザインについて何か提案はありますか？はい、地域ごとの天気を色分けして一目でわかるようにし、特に注意が必要な地域は赤や黄色などの強調色を使って視覚的に警告する形にしたいと思います。また、スマホでの閲覧を考慮して、縦長のデザインも準備しています。素晴らしいですね。それでは、最後に公表のタイミングについて確認しましょう。鈴木さん、ウェブサイトとSNSでの情報発信はどの時間に行う予定ですか？ウェブサイトには午前7時に詳細な予報を掲載し、SNSではその後すぐに速報を流します。また、午後1時と夕方6時に追加の更新情報を発信する予定です。承知しました。それでは、このスケジュールで進めるということで、皆さん問題ないでしょうか？はい、問題ありません。では、今日の会議はここまでとします。皆さん、準備をよろしくお願いします。お疲れ様でした。明日の天気予報公表方法に関する会議 議事録明日の天気予報公表方法に関する会議 議事録日時: 2024年5月15日時間: 10:00 AM - 11:00 AM場所: 第2会議室出席者司会者: 田中さん気象予報士: 佐藤さん広報担当: 鈴木さんSNS担当: 山田さんデザイン担当: 小林さん議題明日の天気予報の概要公表方法の検討SNSでの公表方法インフォグラフィックのデザイン公表のタイミング確認議事内容1. 明日の天気予報の概要佐藤さん（気象予報士）:- 明日の天気は全国的に晴れ。- 一部地域で午後から雨が降る予報が出ている。- 特に北部では雷を伴う激しい雨になる可能性がある。- 気温は平均して25度前後。2. 公表方法の検討鈴木さん（広報担当）:- 公式ウェブサイトに詳細な予報を掲載。- SNSやメルマガで速報を流す予定。- 特に激しい雨の地域については注意喚起を強調。3. SNSでの公表方法山田さん（SNS担当）:- インフォグラフィックを使って視覚的にわかりやすい情報を発信。- リアルタイムで更新されるストーリーズの活用。4. インフォグラフィックのデザイン小林さん（デザイン担当）:- 地域ごとの天気を色分けし、特に注意が必要な地域は赤や黄色などの強調色で視覚的に警告。- スマホでの閲覧を考慮して、縦長のデザインも準備。5. 公表のタイミング確認鈴木さん（広報担当）:- ウェブサイトには午前7時に詳細な予報を掲載。- SNSではその後すぐに速報を流す。- 午後1時と夕方6時に追加の更新情報を発信。決定事項ウェブサイトとSNSでの情報発信スケジュールを以下の通りに実施:ウェブサイト: 午前7時SNS: ウェブサイト更新後すぐ追加更新: 午後1時、夕方6時アクションアイテム佐藤さん: 明日の天気予報の詳細を準備。鈴木さん: ウェブサイトおよびSNSでの情報発信の準備。山田さん: SNS用のインフォグラフィックおよびストーリーズの準備。小林さん: インフォグラフィックのデザイン作成。次回会議日時: 2024年5月16日 午前10時議題: 公表後の反響の確認および改善点の検討結論文字起こしサービスは多くの競合がありますが、会議などの機密事項を含む内容を外部のサービスに任せるのは難しいです。しかし、Googleドライブをマウントして利用すれば、情報漏洩のリスクを低く抑えた状態で音声データをテキストデータに変換できるため、おすすめです。

音声認識モデルの精度を検証

ENECHANGE VPoTの岩本 (iwamot) です。2024年4月～6月の四半期から、社内I/O Dayを試験的に始めています。「プロダクト開発や事業課題の解決に活用できそうな技術について、集中的にインプット／アウトプットする日を宣言する制度」のことです（くわしくは別の機会にお伝えします）。多くのエンジニアが本日5月15日にI/O Dayを宣言していたので、ぼくも乗っかってみました。お祭り感があって、いいですね。ぼくが取り組んだテーマは、Slackのfiles.upload API廃止対応でした。2025年3月までに、新しいAPIに移行する必要があるんですよね。まだ時間はあるものの、ボリューム的にちょうどよさそうなので選びました。今回の記事では、Google Apps Scriptからの呼び出し方をどう変えたのかご紹介します。これから廃止対応を進める方の参考になれば幸いです。変更前のコードまず、変更前のコードをご紹介します*1。とあるクラスの uploadFile メソッドです。files.upload APIをシンプルに呼んでいます。  /**   * ファイルをアップロードする   *   * @param {Blob} fileBlob - ファイル   * @param {String} filename - ファイル名   * @return {String} アップロードしたファイルURL   */  uploadFile(fileBlob, filename) {    const options = {      payload: {        token: this.oauthToken,        file: fileBlob,        filename: filename,      },    };    const response = UrlFetchApp.fetch(      "https://slack.com/api/files.upload",      options    );    const responseBody = response.getContentText();    const data = JSON.parse(responseBody);    if (!data.ok) {      throw new Error(data);    }    return data.file.permalink;  }新しいアップロード手順新しいAPIでのファイルアップロード手順は、下記のとおりです。files.getUploadURLExternal API を呼び出してファイルアップロードに使用する https://files.slack.com/upload/v1/... URL とファイル ID を取得するhttps://files.slack.com/upload/v1/... URL に POST リクエストを送信してファイルをアップロードするfiles.completeUploadExternal API にファイル ID に加えて チャンネル ID などを送信して、アップロード処理を完了させるqiita.com変更後のコード変更後のコードは下記のようになりました。新しいアップロード手順を素直に実装した形です。クラスにメソッドを3つ追加しています。  /**   * ファイルをアップロードする   *   * @param {Blob} fileBlob - ファイル   * @param {String} filename - ファイル名   * @return {String} アップロードしたファイルURL   */  uploadFile(fileBlob, filename) {    const [fileUploadUrl, fileId] = this.getFileUploadUrl(      filename,      fileBlob.getBytes().length    );    const options = {      method: "post",      payload: fileBlob,    };    const response = UrlFetchApp.fetch(fileUploadUrl, options);    Logger.log(response);    this.completeFileUpload(fileId);    return this.getFilePermalink(fileId);  }  /**   * ファイルアップロード用URLを取得する   *   * @param {String} filename - ファイル名   * @param {Number} length - ファイルサイズ   * @return {String[]} ファイルアップロード用URL、ファイルID   */  getFileUploadUrl(filename, length) {    const options = {      method: "get",      headers: {        Authorization: "Bearer " + this.oauthToken,      },      payload: {        filename: filename,        length: length.toString(),      },    };    const response = UrlFetchApp.fetch(      "https://slack.com/api/files.getUploadURLExternal",      options    );    Logger.log(response);    const responseBody = response.getContentText();    const data = JSON.parse(responseBody);    if (!data.ok) {      throw new Error(data);    }    return [data.upload_url, data.file_id];  }  /**   * ファイルアップロード処理を完了する   *   * @param {String} fileId - ファイルID   */  completeFileUpload(fileId) {    const options = {      method: "post",      headers: {        Authorization: "Bearer " + this.oauthToken,      },      contentType: "application/json",      payload: JSON.stringify({        files: [{ id: fileId }],      }),    };    const response = UrlFetchApp.fetch(      "https://slack.com/api/files.completeUploadExternal",      options    );    Logger.log(response);    const responseBody = response.getContentText();    const data = JSON.parse(responseBody);    if (!data.ok) {      throw new Error(data);    }  }  /**   * ファイルのURLを取得する   *   * @param {String} fileId - ファイルID   * @return {String} ファイルのURL   */  getFilePermalink(fileId) {    const options = {      method: "get",      headers: {        Authorization: "Bearer " + this.oauthToken,      },      payload: {        file: fileId,      },    };    const response = UrlFetchApp.fetch(      "https://slack.com/api/files.info",      options    );    Logger.log(response);    const responseBody = response.getContentText();    const data = JSON.parse(responseBody);    if (!data.ok) {      throw new Error(data);    }    return data.file.permalink;  }いくつか補足します。整数化はtoStringで  getFileUploadUrl(filename, length) {    const options = {      method: "get",      headers: {        Authorization: "Bearer " + this.oauthToken,      },      payload: {        filename: filename,        length: length.toString(),lengthを文字列に変換しているのは、数値型のままだと 12345.0 のような値がPOSTされ、エラーになるためです。配列を含むペイロードはJSON.stringifyで  completeFileUpload(fileId) {    const options = {      method: "post",      headers: {        Authorization: "Bearer " + this.oauthToken,      },      contentType: "application/json",      payload: JSON.stringify({        files: [{ id: fileId }],      }),    };JSON.stringifyしているのは、files.completeUploadExternal APIのペイロードで配列を指定するのに必要なためです。contentTypeにも要注意。くわしくは下記の記事をご参照ください。qiita.comまた、トークンをヘッダに移動したのは、JSONペイロード内で渡しても無視されてしまうためです。トークンはヘッダに含めるようドキュメントでも推奨されています。We prefer tokens to be sent in the Authorization HTTP header of your outbound requests.api.slack.comfiles.info APIを呼ぶならfiles.readの許可を  getFilePermalink(fileId) {    const options = {      method: "get",      headers: {        Authorization: "Bearer " + this.oauthToken,      },      payload: {        file: fileId,      },    };    const response = UrlFetchApp.fetch(      "https://slack.com/api/files.info",      options    );多くのユースケースでは、アップロードしたファイルのURLが必要になることでしょう。今回のコードもそうでした。ファイルのURLを取得するには、files.info APIが使えます（他の方法もあるかもしれませんが、調べていません）。ただし、files.info APIを呼び出すには files.read スコープが必要です。files.write だけではエラーになります。おわりに以上、Slackのfiles.upload API廃止に備えて、Google Apps Scriptのコードに手を入れた例をご紹介しました。Slack APIもGoogle Apps Scriptも不慣れでしたが、社内I/O Dayを活用することで、コードリーディングからブログ投稿まで1日で終えられました。次の四半期でも、また何か取り組めたらと思っています。追記 (2024-05-16)HTTPメソッドを明示的に指定するようコードを変更しました。記事公開時には method: "post"  などの指定をしていませんでした。瀬良さん、フィードバックありがとうございました！ありがとうございます！一応どの HTTP メソッドでも動くんですが POST の方が安全かと思うので options に method: "post", を追加しておいた方がよいと思います。あと、この記事からリンクさせていただきました！ https://t.co/1QizWfF65i #SlakDevJP— Kazuhiro Sera (瀬良) (@seratch_ja) 2024年5月15日   *1:記事内のコードはすべてMITライセンスです

Slackのfiles.upload API廃止に備え、Google Apps Scriptのコードに手を入れる

CTO室のkazです。ゴールデンウィーク後、一週間の入院生活中にベッドの上でこれを書いています。目的Easy-RSAで作成したサーバ証明書をAWSClientVPNの相互認証用クライアントVPNエンドポイントで使用します。クライアントVPNエンドポイントの作成についてはこちらを参照ください。概要通常、AWSCertificateManager(ACM)を利用すれば、DNS認証によるサーバ証明書の自動更新が適用され、定期的な更新作業が不要となります。しかしながら、ACMは公開SSL/TLS証明書の管理に特化しており、クライアント証明書の生成機能は提供されていません。したがって、相互認証用のクライアント証明書を作成する場合、ACMを使用することはできません。そのため、代替手段としてEasy-RSAを利用することが適切です。Easy-RSAは証明書や鍵の生成、署名、管理などを行うためのツールセットであり、VPNサーバなどで相互認証用のクライアント証明書を手動で生成するのに適しています。手順として認証局の作成：% git clone https://github.com/OpenVPN/easy-rsa.git% cd easy-rsa/easyrsa3% ./easyrsa init-pki% ./easyrsa build-ca nopass証明書の作成：Easy-RSAを使用して、サーバ証明書とクライアント証明書、その秘密鍵を生成します。これにより、VPNサーバの識別と暗号化のための鍵が作成されます。% ./easyrsa build-server-full server.domain.com nopass% ./easyrsa build-client-full client1.domain.tld nopassサーバ証明書のインポート:AWSの管理コンソールで、ClientVPNの設定ページに移動し、サーバ証明書とその秘密鍵をアップロードします。これにより、AWSClientVPNサービスがこの証明書を使用してサーバを認証できるようになります。% mkdir ~/custom_folder/% cp pki/ca.crt ~/custom_folder/% cp pki/issued/server.crt ~/custom_folder/% cp pki/private/server.key ~/custom_folder/% cp pki/issued/client1.domain.tld.crt ~/custom_folder% cp pki/private/client1.domain.tld.key ~/custom_folder/$ cd ~/custom_folder/% aws acm import-certificate --certificate fileb://server.crt --private-key fileb://server.key --certificate-chain fileb://ca.crtクライアント証明書のACMへのインポート:クライアント証明書を AWSCertificateManager(ACM) にインポートすることは可能です。ACMは主に公開 SSL/TLS証明書の管理に特化していますが、クライアント証明書も同様に扱うことができます。そのため、クライアント証明書を AWS管理コンソールからACMにインポートし、その後、相互認証用のクライアントVPNエンドポイントで使用することができます。VPNクライアントの構成:クライアントは、クライアント証明書とその秘密鍵を使用して VPN接続を確立するために、適切なVPNクライアントソフトウェアを構成する必要があります。VPNクライアントソフトウェアには、AWSの公式クライアントや、他のサードパーティ製品が使用できます。証明書の適宜更新% ./easyrsa renew server nopass% mkdir ~/custom_folder2% cp pki/ca.crt ~/custom_folder2/% cp pki/issued/server.crt ~/custom_folder2/% cp pki/private/server.key ~/custom_folder2/% cd ~/custom_folder2/% aws acm import-certificate --certificate fileb://server.crt --private-key fileb://server.key --certificate-chain fileb://ca.crt注意点Easy-RSAでオレオレ認証局を作成し、その認証局で生成した証明書は、一般的な公的認証局（CA）によって署名された証明書とは異なり、その信頼性やセキュリティのレベルも異なります。そのため、AWSCertificate Manager（ACM）では、一般的な公的認証局が提供する方法であるDNS認証やEmailドメイン認証などを使用して証明書を認証することはできません。オレオレ認証局で生成された証明書は、自己署名されたものであり、信頼性を確保するためには、クライアント側で明示的に信頼される必要があります。そのため、ACMではこのような証明書を扱うことはできません。したがって、オレオレ認証局で生成された証明書を使用する場合、通常は手動で証明書を管理し、VPNクライアントなどの各エンドポイントで信頼される証明書として設定する必要があります。

Easy-RSAで作成したサーバ・クライアント証明書をAWSで利用する

ENECHANGE所属のエンジニア id:tetsushi_fukabori こと深堀です。 今回は2024年第1Q（弊社は12月決算なので1-3月が第1Qです）に実施したdev環境のインフラ構成変更と、それによるコスト削減を紹介します。今回はAWS Transit Gatewayというサービスを利用してNAT Gatewayの台数を減らし、時間コストを削減しました。この記事を届けたい人NAT Gatewayのコスト削減案を考えている人円安ドル高と戦うソフトウェアエンジニアこの記事を届けたい人「dev環境統合」プロジェクトの概要dev環境ネットワークのBefore/AfterAWS Transit Gatewayとはdev環境統合による影響コスト面のトレードオフアプリへの影響dev環境統合の進め方1. 影響説明と参加意向ヒアリング2. 事前見積もり3. 集約NAT Gatewayの構築4. 集約後IPへの移行5. 集約NAT Gatewayへの移行コスト削減効果まとめ「dev環境統合」プロジェクトの概要今回の対応はCTO室で当初「dev環境統合」と呼ばれたコスト削減プロジェクトから始まっています。もう少し具体的な話をしましょう。ここで本番環境でも検証環境でもない環境を「dev環境」と呼ぶことにします。このため、サービス・環境をまたいで同一のクラウドインフラリソースを共用することでコストを削減できないか、というのは「dev環境統合」プロジェクトです。dev環境ネットワークのBefore/After早速ですがBefore/Afterを見ていきます。BeforeAfterBeforeの要点は以下のとおりです。AWSアカウント内に複数のVPCが存在するVPC内に複数のサブネットが存在するサービスは複数の環境（本番/検証/dev1/dev2/...）をもつ環境は複数のサブネットをもち、環境内にNAT Gatewayを単一または複数もつこともある今回コスト削減の対象として考えたNAT Gatewayは別の外部サービスに接続をしたいサービスに配置されています。Afterの要点は以下のとおりです。NAT Gatewayは全体で2つ（AZ毎に1つずつ、2 AZ分）に集約各VPCに配置した集約用のサブネットにTransit Gateway AttachmentをアタッチするVPCをまたいでTransit Gatewayでネットワークを接続し、サービスのアプリケーションからインターネットへの通信は集約したNAT Gatewayを通過するこの対応によりAfterではNAT Gatewayの数が大きく減ります。AWS Transit Gatewayとはでは今回の対応で使用したAWS Transit Gatewayというサービスについて軽く説明します。aws.amazon.comTGWは複数のネットワーク間を相互接続するネットワークサービスです。AWS Transit Gateway は、Amazon Virtual Private Cloud (VPC) とオンプレミスネットワークを中央ハブで接続します。この接続により、ネットワークが簡素化され、複雑なピア接続関係がなくなります。Transit Gateway は、拡張性の高いクラウドルーターとして機能し、新しい接続は 1 回だけ行われます。TGWはネットワークを相互に接続するためのリソースで、ネットワークとTGWを接続するリソースがTGW Attachmentです。ルートテーブルでアタッチメントに向き先を指定すればTGWにトラヒックが流れます。TGWおよびTGW Attachmentはマネージド冗長化されています。ALBなどと同じですね。条件として接続するネットワークのIPレンジが相互に重複しない必要があります。dev環境統合による影響本対応はアプリ/インフラ双方に影響があります。コスト面のトレードオフコストは以下のように増減します。   時間コスト  流量コスト  減少  $0.062 x 台数 / 時 （NAT Gateway）$0.005 x 台数 / 時 （パブリックIP）  -  増加  $0.062 x 2台 / 時 （NAT Gateway）$0.070 x アタッチメント数 / 時 （TGW） $0.02 / GB （TGW） 流量コストはNAT Gatewayの分があるのですが、この対応前後でNAT Gatewayを通る流量は変わらず、集約前の個々のNAT Gatewayを通るか集約後のNAT Gatewayを通るかの差しか無いので表からは除いています。ポイントは以下のとおりです。減少幅はNAT Gatewayの台数依存増加幅はTGW Attachmentの個数依存時間あたりコストはリソース数が同じならTGWの高くコストは増加するTGW Attachmentは集約先にも設置が必要なため、TGW Attachment 1つ分は必ずコスト増になる流量コストは純増するコストを削減するためには「新設するTGW Attachment数よりも削減するNAT Gateway数が十分上回る」ことと「流量コストの増加が時間コストの減少に対して小さい」ことが必要になります。弊社の場合、以下のような状態だったためどちらもクリアしていました。VPCを共用しているサービス・環境があり、個々のNAT GatewayがTGW（VPCに1つでよい）に置き換えられるNAT Gatewayを複数AZに冗長化しているサービス・環境はTGWに置き換えられるdev環境は流量が少なくコストが極小もしECSをつかっていてイメージPullが多い…とか、環境ごとにVPCが分かれていてVPC内のNAT Gatewayは冗長化していない…といったような状況ではコストメリットが出ないことが考えられます。アプリへの影響アプリへの影響は「外向け通信の送信元IPアドレスが変化する」点です。インフラ的にはNAT GatewayにアタッチするEIPが変わっているので当然なのですが、アプリ的には小さくない影響です。このような前提があるためバッタン切り替えではなくロールバックも視野に入れて移行を進めるとよいでしょう。dev環境統合の進め方今回は以下のステップで移行を進めました。1. 影響説明と参加意向ヒアリング新たな集約NAT GatewayやTGWの設置の前に、まず候補となるNAT Gatewayを洗い出しました。意向に際してはむしろアプリチームの負荷が高く、外部サービスや顧客説明、作業依頼、検証といった様々なタスクが発生します。2. 事前見積もり参加するアプリが決まったことで初めて見積りができるようになります。弊社は構築している環境が多かったため、アプリにヒアリングする際に「実は不要だったNAT Gateway」もそれなりの個数が見つかりました。集約可能なNAT Gatewayの数と、集約に参加するアプリが属するVPCの数がわかれば削減効果が計算できます。このコスト削減効果の規模感で実際に対応するかを判定します。3. 集約NAT Gatewayの構築集約NAT Gateway用のVPCやサブネット、IGW、NAT Gateway、ルートテーブルなどのネットワーク系リソースを作成します。4. 集約後IPへの移行アプリチームに変更後に利用するIPアドレスを通知します。弊社ではtoBのサービスもそれなりに数があり、この作業に一番時間がかかりました。5. 集約NAT Gatewayへの移行新IPのホワイトリスト追加ができたらネットワークの経路を集約NAT Gatewayに移行します。具体的な作業は以下のステップです。移行するアプリのVPC内にTGW Attachment用のサブネットを作成（AZの個数分）TGW Attachmentをアタッチし、TGWのルートテーブルに以下の定義を追加するアプリVPCのCIDR範囲宛のトラヒックをアプリVPCにアタッチしたTGW Attachmentにルーティング集約NAT Gateway用VPCのCIDR範囲宛のトラヒックを集約NAT Gateway用VPCにアタッチしたTGW Attachmentにルーティング（初回のみ）デフォルトルートとして集約NAT Gateway用VPCにアタッチしたTGW Attachmentにルーティング（初回のみ）集約NAT Gateway用VPCのNAT Gatewayが設置されているサブネットのルートテーブルに以下を追加アプリVPCのCIDR範囲宛のトラヒックをTGW Attachmentにルーティング集約NAT Gateway用VPCのCIDR範囲宛のトラヒックをlocalにルーティング（初回のみ）デフォルトルートとして集約NAT Gateway用VPCのIGWにルーティング（初回のみ）アプリVPCのアプリインスタンスが設置されているサブネットのルートテーブルのデフォルトルートをVPC内のNAT GatewayからTGW Attachmentに変更外部サービスへの接続確認外部サービスのホワイトリストから現用NAT Gatewayに付与しているIPアドレスを削除現用NAT GatewayとEIPを削除ポイントは太字の箇所です。上記の4. の手順がネットワークの切り替えタイミングですが、本プロジェクトではこのタイミングで通信断などは検知していません。コスト削減効果コストの削減効果を確認します。本プロジェクトは2024/02で実施しました。このため2024/01と2024/03のコスト比較で削減コストを確認しました。25%のコストダウンに成功結果として25%のコストダウンに成功しました！  絶対値はネットワークの規模に寄りますが、十分な削減率ではないでしょうか？削減の効果を測定するため、Cost Explorerで以下の設定で計測しています。使用タイプAPN1-NatGateway-HoursAPN1-TransitGateway-HoursAPN1-TransitGateway-Bytes環境（タグ）dev環境のみディメンション使用タイプ粒度月別なお使用タイプ「APN1-NatGateway-Bytes」は対応前後で本対応に関するコストが変化しないため含めていません。まとめ本プロジェクトではdev環境のNAT GatewayをTGWで集約することでコスト削減をはかりました。アプリチームと一体で様々な課題に挑戦したい方、ENECHANGEの採用サイトをぜひご覧ください。engineer-recruit.enechange.co.jp

オールチームで進めよう！ 〜AWS Transit Gatewayによるコスト削減事例〜

2023年12月6日にENECHANGE株式会社の主催にて「耐障害性向上・パフォーマンス改善・負荷軽減を実現する？事業を支えるSREのノウハウを共有」というテーマでのエンジニア向けイベントをオンライン開催しました。テックベンチャーであるアソビュー株式会社（以下、アソビュー）・Chatwork株式会社（以下Chatwork）・ENECHANGE株式会社（以下ENECHANGE）のSREエンジニアが登壇し、事業特性に合わせてシステムを安定稼働させながら成長を支えていく各社の取り組みについてお話ししていただきました。本記事ではイベントでの各登壇者のお話をサマライズ版でお届けします。（執筆者：菅谷望）アソビューSREで実施した各種最適化の視点について登壇者: 鈴木 剛志さん（アソビュー株式会社　SREユニット ユニットリーダ）アソビューについてアソビューは、「生きるに、遊びを。」をミッションにチケットの電子販売や、レジャー施設や体験事業者向けの業務支援ツール、地方自治体向けの業務改善サービスを提供しています。2022年8月実績において、月間PV数3,800万、会員数1,000万人を誇る遊び予約サイト「アソビュー！」では、遊園地やテーマパークのチケット、温泉の入場券といった遊びの選択肢を広げるチケットを豊富に取り揃えています。安定稼働する上で、余剰リソースを見つけていくための視点システムの性能限界は、ハードウェアのスペックやソフトウェアの設計によって決まります。この上限を意識しながら、サービスの運用に支障がないかを見極めながら運用していく必要があります。1年前の課題は、以下の2点でした。インフラのスペックの見積もりが甘く、過剰なリソースで運用していた過剰なリソースが使われているために、サービスの成長に伴う限界が見えにくく、リスクのある運用を行っていたこれらの課題を解決するために、まず、ビジネス上重要な指標を特定し、その指標の性能限界と必要なインフラスペックの相関を整理しました。これにより、あるインフラスペックでどの程度の処理を捌けるかを把握することができました。余剰リソースをどのような手法で削減したか安定稼働基準を基にしたインフラコストの最適化アソビューでは、人気チケットの発売直後に負荷が急上昇する傾向があります。ただし、このスパイクは平常時の5倍以内に収まるという傾向があることがわかりました。この傾向を踏まえて、通常運用時に5倍のスパイクに耐えられるようインフラを最適化し、安定した稼働を確保しました。また、人気チケットを購入しようとするユーザーの中には、一定の比率で発売日の少し前に様子を見に来るという行動を取ることが普段の観察結果からわかりました。この事前アクセスのトラフィックをベースにして実際の負荷を予想し準備を行うことで、安定したサービスの提供に繋げることができました。CPU利用率を基にしたインフラコストの最適化また、時間帯や日付でアクセス数のトレンドが変わるため、スケールが容易な仕組みとして下記の技術を使うことを検討しました。Aurora Serverless v2(DB)HPA(Kubernetes)AuroraをServerlessに切り替えたときのコスト比較を行いました。この比較から、下記のことがわかりました。CPU使用率が常に20%以上ならプロビジョニングが有利CPU使用率が、常に10%以上が1年継続する見込みならプロビジョニングRIが有利CPU使用率が、常に7%が3年以上継続する見込みならプロビジョニングRIが有利アソビューの現状として夜間のアクセスは少なく、平均するとCPU使用率は10%以内に収まることが予想されました。また、繁忙期だけスペックを変更するというオペレーションも運用負荷になるため、AuroraをServelessに変更することでAurora MySQLのコスト最適化を行う方針を取りました。SRE初心者が急成長しているEV充電サービスの安定稼働にコミットした話登壇者: 佐々木 徹さん（ENECHANGE株式会社　EV充電サービス事業部 開発チーム）ENECHANGEについてENECHANGEは、「エネルギーの未来をつくる」をミッションに掲げ、エネルギーの4D革命を推進するエネルギーベンチャー企業です。日本・欧州・中東と世界でサービスを展開しています。現在の社員数は約270名です。採用ページでは、募集職種や応募方法など、採用に関する情報を詳しくご紹介しています。ぜひご覧いただき、ご関心ある方はご応募ください。engineer-recruit.enechange.co.jpまた、ENECHANGEの事業内容や働き方などに関するニュースやインタビュー記事などもWantedlyやnoteで公開しています。ぜひご覧いただき、ENECHANGEの魅力を知っていただければと思います。EV充電サービスについて日本政府が掲げた、「2035年までに新車販売の100%を電動車にする」という目標を背景に、ENECHANGEでは2021年からEV充電エネチェンジというサービスを運営しています。Webアプリでは、充電スポットの検索や充電の開始・終了などの基本機能に加え、EVドライバーにとって便利な機能を提供しています。システム構成についてENECHANGEのEV充電エネチェンジのサーバーは大きく分けて、以下の3種類から構成されています。フロントサーバー：アプリのAPIサーバーや、Webページの配信、外部システムとの連携を行う。充電器管理サーバー：充電器1台ずつと接続して、ステータス管理や、充電の開始・終了などの操作を行う。データベース：充電スポットの情報や、充電履歴などのデータを保存する。ENECHANGEのEV充電サービスの充電器管理サーバーは、充電器1台ごとにWebSocketで接続して、充電器の操作や状態に関わるメッセージをJSON形式のデータとして送受信しています。この特徴により、充電器の状態をリアルタイムで把握し、充電の開始・終了などの操作を効率的に行うことができます。致命的な障害と解決策について障害の内容と対策2023年4月、充電器管理サーバがダウンし、多くの充電器で充電ができなくなる障害が発生しました。また、2023年6月にはデータベースがダウンし、いずれの障害でも多くの充電器で充電ができないという致命的な障害が発生しました。この障害の応急措置として以下の対応を行いました。▼4月の障害コンテナ1台あたりの同時接続数緩和のためのスケールアウト&オートスケール導入負荷の原因となっていたバッチ処理の実行頻度を下げた▼6月の障害データベースのスケールアップこれらの対応により、データベースのCPU使用率は一時的には安定しました。しかし、その後も時折データベースの使用率が急上昇し、アラートが発生していました。さらに検証した結果、使用率が急上昇するタイミングは主に充電器管理サーバのデプロイと重なることが多いことが判明しました。障害の原因以下の 3点を理由にデプロイ時にリソース不足に陥ったことが、障害の根本的な原因であると仮説を立てました。充電器管理サーバーのデプロイに伴って旧コンテナが落ち、各充電器とのOCPP（WebSocket）接続が一斉に切断されている各充電器は充電器管理サーバーとの接続が切れると、即時再接続される仕様になっている全充電器からの再接続要求が集中し、充電器管理サーバーがパンクしてしまった障害への解決策まず、障害への解決策として以下の2つの方法を検討しました。1. Exponential Backoffの導入再接続間隔を指数関数的に後退させるExponential Backoffアルゴリズムの導入を試みました。しかし、充電器管理サーバーのクライアントは充電器そのものであり、クライアント側の改修はメーカーにファームウェア開発を依頼する必要がありました。そうなるとクライアント側での実装が必要になり時間とコストがかかるため、この方法は不採用となりました。2. Blue/Green デプロイの課題以前から導入していたAWS CodeDeployを用いたBlue/Green デプロイでは、線形デプロイオプションにより、Blue環境からGreen環境へ設定に応じてトラフィックを置き換えることができます。しかし、以下の問題点が懸念されたため不採用となりました。新規接続のみGreen環境へ誘導されるため、WebSocketで接続済みのクライアントはBlue環境と接続されたままになる。Blue環境が破棄されるタイミングで既存の接続が切断され、再接続が集中する。そこで、再接続が集中しない仕組みを作るためにGraceful Updateの仕組みを独自で実装することにしました。この方法で無事障害を回避することができ、以下のメリットが得られました。デプロイ時に高負荷となることがなくなった充電器管理サーバーのデプロイによる障害が発生しなくなったデプロイへの心理的ハードルが低くなり、継続的改善のサイクルが早まった何より、サービスにとって大きな課題をシンプルな方法で解決できたことは、非常に価値のあることだと考えています。今後の計画について今後、EV充電インフラサービスの土台を整えるため、以下の3点の取り組みを実施する予定です。3万台を想定した負荷試験を実施して問題点を洗い出す必要に応じてリアーキテクチャを実施するSRE業務が属人化しているので、自動化の推進やSRE文化の醸成・浸透をするChatwork流Kubernetesの運用方法登壇者: 桝谷 花世さん（Chatwork株式会社　SRE部）「Chatwork」とは「Chatwork」はグループチャットやタスク管理、ファイル管理、ビデオ/音声通話などができるビジネスチャットです。2023年9月末時点では導入社数が42.1万社以上となっています。SREに求められる3つの目標とは？ChatworkのSREには、以下の3つの目標が求められます。【1】コストの最適化ビジネスをしていく上で利益を上げるためには、インフラコストの削減が求められます。そのため、SREでは、インフラの利用状況を分析し、無駄なコストを削減するための取り組みを行っています。【2】安定稼働ビジネスチャットサービスは、ビジネスの重要なインフラとして利用されています。そのため、サービスが停止すると、ユーザーの業務に大きな影響を与えてしまいます。【3】アジリティの向上ユーザーのニーズは常に変化するため、ユーザーの要望に柔軟かつ積極的に対応しサービスをアップデートし続ける必要があります。そのため、SREでは、アジリティの向上を実現するための取り組みを行っています。コストの最適化と安定稼働における課題と解決策について「Chatwork」はビジネスチャットサービスであり、日中帯のアクセスが集中する傾向にあります。そのため、日中帯のアクセスを想定してサーバーを常時稼働させておくと、夜間帯の稼働率が低下し、コストがかさんでしまいます。そこで、Chatworkでは、Kubernetesのスケーリング機能を活用して、日中帯のアクセスに合わせてサーバーを自動的にスケールさせています。しかし、単純にPodをオートスケールすると、以下の2つの課題が生じます。Amazon EC2の台数が増加するため、コストが高くなる。Podがスケールアウトする際には、Amazon EC2インスタンスの起動に数分かかるため、サービスが不安定になる。ここからは、それぞれの課題を解決する取り組みについて紹介します。① EC2の台数が増加するため、コストが高くなるAmazon EC2の購入オプションの1つである「スポットインスタンス」が以前よりも安定してきたことや、「Chatwork」のアプリがステートレスにできていることから、Amazon EKSのNodeにAmazon EC2スポットインスタンスを導入してコストを削減しています。② Podがスケールアウトする際には、EC2インスタンスの起動に数分かかるため、サービスが不安定になるChatworkでは、社内ツールであるballoonを使ってあらかじめ余剰Nodeを確保しています。balloon Podを追加すると下記のイメージになります。このような仕組みにすることで、Nodeの起動時間を待つことなく、チャットワークのアプリを起動することができます。そのため、サービスが不安定になることなくスケールが可能となっています。アジリティの向上における取り組みについてChatworkでは、開発者がアプリのソースコードをmainブランチにマージすると、自動的にビルド・プッシュ・マニフェストのアップデートが行われます。その後、ArgoCDがポーリングを行い、アプリの状態が正常であることを確認します。ArgoCDで問題がなければ、開発者はArgoCDの画面からボタンを押すことで、アプリを本番にリリースすることができます。この仕組みにより、SREの介入を必要とせずに、開発チームが好きなときにアプリをリリースすることができます。アジリティを実現するためには、開発者がスピード感を持って機能開発を進めることが重要です。そのためには、開発者が開発しやすい環境を整えることが求められます。ここからはその取り組みについて紹介します。検証時にSREがボトルネックにならない運用自分専用の使い捨て検証環境の構築開発・本番へのAWSリソースの構築1. 検証時にSREがボトルネックにならない運用本番アカウントでは、Amazon Route53の設定変更などの変更を行う際には、必ずSREチームを通す必要がありました。そのため、検証のために設定変更をしたい場合でも、SREチームに依頼して承認を得る必要があり、検証のスピードが遅れるという課題がありました。そこで、検証環境と本番環境を分けるとともに、検証環境には開発チームに強い権限を付与しました。この取り組みにより、開発チームは検証のために必要な設定変更を自ら行うことができるようになりました。その結果、開発チームの中で全てを完結することができ、検証のスピードが上がり開発者体験が向上しました。2. 自分専用の使い捨て検証環境の構築当初は検証用の環境が一つしかなかったので、開発者が検証を行う際には、検証環境を他の開発者が使用していないかどうかを確認する必要がありました。そのため、検証環境の使用タイミングの調整や待ち時間が発生し、開発効率が低下していました。そこで、Pull Request上でコメントをするだけで自分専用の検証環境が構築できるような仕組みを作りました。これにより環境の調整が必要なくなり、開発者体験が向上しました。3. 開発・本番へのAWSリソースの構築TerraformとAtlantisを使い、Pull RequestベースでAWSリソースを構築できるようにしました。このような仕組みを取り入れることで、SREが関与することなく開発チーム内でインフラ構築を安全にできるようになりました。以上となります。イベント概要、ならび各登壇者から共有いただいた資料については以下ページをご確認ください。enechange-meetup.connpass.com今回のイベントでは、各社のSREの取り組みから、事業特性に合わせた具体的な取り組みを共有していただきました。SREは、ユーザー体験とビジネス成長の狭間で常にバランスを取る必要があります。イベント参加者の方々にも、現場で問題に直面する難しさや魅力を感じていただけたのではないでしょうか。本記事が、エンジニアの皆さんにとっての実践的な学びや、キャリア形成に役立てば幸いです。

事業を支えるSREのノウハウを共有！ ENECHANGE主催イベント・レポート

VPoTの岩本 (iwamot) です。ENECHANGEでは、所属エンジニアの個人的なアウトプットをまとめたハブサイト「ENECHANGE Engineers' Articles」を運用しています。engineer.enechange.co.jpこのハブサイトは、OSSのTeam Blog Hubで構築したものです。これを使うと、メンバーのアウトプットが簡単にまとめられます。先日、ハブサイトのデプロイ先をVercelからCloudflare Pagesに移行しました。この記事では、なぜ移行しようと思ったのか、また、どのように移行したのか書いてみます。なぜ移行しようと思ったのかデプロイ先をVercelからCloudflare Pagesに移行しようと思ったのは、下記の理由からでした。Cloudflareについて学べる費用が節約できるCloudflareについて学べる昨年10月にVPoTを拝命してから、それまで以上に、未導入の技術への関心が強くなってきました。特にCloudflareについては、ENECHANGEでの利用実績はないものの、エッジでいろんなことができそうで気になるところです。この四半期で何か試せないかな、と考えたときに浮かんだのが、Team Blog Hubの移行でした。費用が節約できるそこで調べてみると、Cloudflare Pagesの無料プランは今のところ商用利用可能であるとわかりました。一方、Vercelでは、無料プランが非営利の個人利用にのみ制限されているため、有料プランを選んだ経緯があります。つまり、Cloudflare Pagesに移行できれば、Vercelの有料プランにかかっていた費用がゼロになります。ENECHANGEの場合、もともと月20ドルと少額でしたが、安いにこしたことはありません。どのように移行したのか実際に試してみると、いくつか詰まったポイントはあったものの、おおむねスムーズに移行できました。以下、Vercelでの運用から手を加えたところをまとめてみます。ビルドが通るようにした環境変数でYarnとNode.jsのバージョンを指定したnext.config.jsを追加した定期ビルドのトリガーをGitHub ActionsからCloudflare Workersに変えたビルドが通るようにした単純にビルドを実行したところ、下記のエラーで失敗しました。13:36:32.186 Detected the following tools from environment: yarn@3.6.3, nodejs@18.17.1（中略）13:36:40.509    ➤ YN0002: │ my-app@workspace:. doesn't provide eslint (p91753), requested by @typescript-eslint/eslint-plugin13:36:40.509    ➤ YN0002: │ my-app@workspace:. doesn't provide eslint (p1d612), requested by @typescript-eslint/parser13:36:40.510    ➤ YN0002: │ my-app@workspace:. doesn't provide eslint (pcb836), requested by eslint-config-prettier13:36:40.510    ➤ YN0002: │ my-app@workspace:. doesn't provide eslint (peb4a8), requested by eslint-plugin-prettier13:36:40.510    ➤ YN0002: │ my-app@workspace:. doesn't provide eslint (p9ef23), requested by eslint-plugin-react-hooks13:36:40.510    ➤ YN0002: │ my-app@workspace:. doesn't provide eslint (pad563), requested by eslint-plugin-react13:36:40.510    ➤ YN0000: │ Some peer dependencies are incorrectly met; run yarn explain peer-requirements <hash> for details, where <hash> is the six-letter p-prefixed code依存関係のエラーですが、これは下記の環境変数を設定することで解決しました。YARN_VERSION: 1.22.19NODE_VERSION: 16.20.2いずれもローカル開発環境のバージョンに合わせた形です。また、Next.jsのドキュメントを参考に、next.config.jsを追加しました。/** * @type {import('next').NextConfig} */const nextConfig = {  output: 'export',}module.exports = nextConfigこれで、ビルドが通るようになりました。定期ビルドのトリガーをGitHub ActionsからCloudflare Workersに変えたこれだけでもよかったのですが、Cloudflare Workersでも定期ビルドが実行できそうなので、好奇心から試してみました。まず、Pagesでデプロイフックを作成し、Workersで下記のコードをデプロイしました。export default {  async scheduled(event, env, ctx) {    ctx.waitUntil(handleSchedule());  },};async function handleSchedule() { let deployHook = "<デプロイフックのURL>"; await fetch(deployHook, {  method: "POST",  headers: {   "Content-Type": "application/json",  }, }); return "Called deploy hook!";};あとは、WorkersでCronトリガーを設定するだけです。現状は 0 1-12 * * * として、無料プランの月間ビルド数上限の500回を超えないようにしています。まとめ以上、Team Blog Hubの移行について、理由と対応内容をまとめてみました。今回の移行は、狙いどおりCloudflareを学ぶスモールステップになったとともに、費用も節約できたので満足しています。副産物として、Workersに触れる機会にもなりました。まだ触れていない機能がCloudflareにはいろいろあるので、引き続き試していこうと思っています。「千里の道も一歩から」ですよね。

Team Blog HubをVercelからCloudflare Pagesに移行しました

VPoTの岩本 (iwamot) です。プレイングマネージャーとして、ENECHANGEの各種システムで使っているAWSの運用も担当しています。先日、アプリチームの同僚から「複数のEC2インスタンスの状態をSlackで確認したい」と相談を受けました。くわしくは後で述べますが、停止中の開発サーバをぱっと探せるようにしたいとの要望です。AWS Chatbotを使えば簡単だろうと軽く引き受けたものの、現状のAWS Chatbotにはいくつかの制約があり、ちょっと手こずりました。今回の記事では、AWS Chatbotに現状どのような制約があり、どう対処したのか書いてみます。相談の背景まず、相談の背景を説明します。開発用インスタンスが9台ある作業が必要になったら、停止済みのインスタンスを探して起動している（実行中のインスタンスは別のエンジニアが作業している）インスタンスはSlackワークフローで起動している（AWS Chatbotを利用）どのインスタンスが停止済みなのか探しづらい（ワークフローの出力がSlackチャンネルで流れてしまうため）AWS CLIでの初期実装適切なクエリを考えるため、まずはAWS CLIで実装してみました。$ aws ec2 describe-instances \  --region ap-northeast-1 \  --filters Name=tag:Name,Values=dev-enechange,dev2-enechange,dev3-enechange,dev4-enechange,dev5-enechange,dev6-enechange,dev7-enechange,dev8-enechange,dev9-enechange \  --query "Reservations[*].Instances[].{Name: Tags[?Key=='Name'].Value | [0], State: State.Name} | sort_by(@, &Name)" \  --output table-------------------------------|      DescribeInstances      |+-----------------+-----------+|      Name       |   State   |+-----------------+-----------+|  dev-enechange  |  stopped  ||  dev2-enechange |  running  ||  dev3-enechange |  running  ||  dev4-enechange |  stopped  ||  dev5-enechange |  running  ||  dev6-enechange |  stopped  ||  dev7-enechange |  stopped  ||  dev8-enechange |  running  ||  dev9-enechange |  running  |+-----------------+-----------+いい感じです。どのインスタンスが停止済みなのか、ぱっと分かります。ちなみに sort_by でソートしないと、意図通りの並び順になりません。$ aws ec2 describe-instances \  --region ap-northeast-1 \  --filters Name=tag:Name,Values=dev-enechange,dev2-enechange,dev3-enechange,dev4-enechange,dev5-enechange,dev6-enechange,dev7-enechange,dev8-enechange,dev9-enechange \  --query "Reservations[*].Instances[].{Name: Tags[?Key=='Name'].Value | [0], State: State.Name}" \  --output table-------------------------------|      DescribeInstances      |+-----------------+-----------+|      Name       |   State   |+-----------------+-----------+|  dev3-enechange |  running  ||  dev2-enechange |  running  ||  dev4-enechange |  stopped  ||  dev5-enechange |  running  ||  dev-enechange  |  stopped  ||  dev6-enechange |  stopped  ||  dev7-enechange |  stopped  ||  dev8-enechange |  running  ||  dev9-enechange |  running  |+-----------------+-----------+AWS Chatbotの制約1：sort_byに未対応準備ができたので、sort_by ありのクエリをAWS Chatbotで実行してみました。@aws ec2 describe-instances  --region ap-northeast-1  --filters Name=tag:Name,Values=dev-enechange,dev2-enechange,dev3-enechange,dev4-enechange,dev5-enechange,dev6-enechange,dev7-enechange,dev8-enechange,dev9-enechange  --query "Reservations[*].Instances[].{Name: Tags[?Key=='Name'].Value | [0], State: State.Name} | sort_by(@, &Name)"  --output tableが、--query パラメータがパースできないと言われてしまいます。AWSサポートに問い合わせたところ、AWS Chatbotは sort_by に未対応なのだそうです。並び順はいったん保留にして、sort_by を抜くことにします。AWS Chatbotの制約2：--outputに未対応@aws ec2 describe-instances  --region ap-northeast-1  --filters Name=tag:Name,Values=dev-enechange,dev2-enechange,dev3-enechange,dev4-enechange,dev5-enechange,dev6-enechange,dev7-enechange,dev8-enechange,dev9-enechange  --query "Reservations[*].Instances[].{Name: Tags[?Key=='Name'].Value | [0], State: State.Name}"  --output tablesort_by を抜いて実行すると、今度は --output には未対応であると警告されました。--output table を指定しても、現状では無視され、表形式にはなりません。これは我慢するしかないでしょう。AWS Chatbotの制約3：デフォルト5件までまた、結果に5件のインスタンスしか表示されていない点も気になります。この点については、--max-results 9 を指定することで、9件すべてのインスタンスが一覧表示できました。@aws ec2 describe-instances  --region ap-northeast-1  --filters Name=tag:Name,Values=dev-enechange,dev2-enechange,dev3-enechange,dev4-enechange,dev5-enechange,dev6-enechange,dev7-enechange,dev8-enechange,dev9-enechange  --max-results 9  --query "Reservations[*].Instances[].{Name: Tags[?Key=='Name'].Value | [0], State: State.Name}"並び順は「インスタンス名と状態を結合してsort」で我慢最後に、棚上げしていた並び順について検討しました。現状、AWS Chatは sort_by には未対応であるものの、sort には対応しているため、文字列または数値のリストであればソートできます。今回はインスタンス名と状態を結合してソートすることにしました。@aws ec2 describe-instances  --region ap-northeast-1  --filters Name=tag:Name,Values=dev-enechange,dev2-enechange,dev3-enechange,dev4-enechange,dev5-enechange,dev6-enechange,dev7-enechange,dev8-enechange,dev9-enechange  --max-results 9  --query "Reservations[*].Instances[].[join(': ', [Tags[?Key=='Name'].Value | [0], State.Name])][] | sort(@)"見た目はともかく、これで「停止中の開発サーバをぱっと探せるようにしたい」との要望に応えられそうです。まとめ以上、ぼくが気づいたAWS Chatbotの現時点の制約と対処についてご紹介しました。簡単にまとめると、下記の通りです。制約対処sort_by に未対応値を結合して sort を使う--output に未対応指定せずに我慢するデフォルト5件まで--max-result N を指定するsort と --output については、AWSサポートによれば、AWS Chatbot担当部署に改善要望として伝えていただけたとのことです。今後の改善に期待しましょう。また、大前提として、空きインスタンスを探す運用がベストだとは思えません。使いたいときに一時的な開発環境をすぐに立てられるよう、整えていきたいと考えています。追記 (2024-04-12)同僚の提案で絵文字を使ったら、さらに見やすくなりました。いろいろできますね。@aws ec2 describe-instances  --region ap-northeast-1  --filters Name=tag:Name,Values=dev-enechange,dev2-enechange,dev3-enechange,dev4-enechange,dev5-enechange,dev6-enechange,dev7-enechange,dev8-enechange,dev9-enechange  --max-results 9  --query "[Reservations[*].Instances[?State.Name=='running'][].Tags[?Key=='Name'][].[join('', [Value, ': running :large_green_circle:'])][], Reservations[*].Instances[?State.Name=='stopped'][].Tags[?Key=='Name'][].[join('', [Value, ': stopped :white_circle:'])][]][] | sort(@)"

AWS Chatbotの現行仕様に耐えつつ、EC2インスタンスの状態をSlackで一覧表示する

VPoTの岩本 (iwamot) です。先日、コーポレート部門の同僚から「弊社Webページの新着情報をSlackに通知したい」と相談を受けました。こういう相談を受けるのも、ぼくの業務のひとつです。腕の見せどころで、やる気が高まります。見てみると、そのページはクライアントサイドで外部APIを呼び出し、取得した新着情報を動的に表示していました。RSSやAtomフィードは提供されていません。外部APIの詳細も不明です。今回の記事では、この相談にどう考えて対応したか書いてみます。正解はないと思うので「自分ならこうする」目線でお読みいただければ幸いです。最終的な構成結論から書くと、最終的には下記の構成に落ち着きました。動的ページのスクレイピングDockerイメージ（Playwrightでスクレイピングし、新着情報RSSを出力）Docker Build Cloud（Dockerイメージのビルド）AWS CodeBuild（Dockerイメージを使ってRSSを出力し、Amazon S3に保存）Amazon EventBridge（定期的にCodeBuildのビルドを実行）RSSの配信Amazon CloudFront（S3に保存したRSSを配信）Slackへの通知IFTTT（RSSの新着アイテムをSlackに通知）ビルドエラーの監視CodeBuildのビルド通知（エラーをSlackに通知）ここに至るまでに、いくつか考えたポイントがあります。スクレイピングに何を使うかまず、スクレイピングに何を使うかです。PlaywrightやPuppeteerなど、いろんな選択肢が考えられます。今回は、Playwrightにしました。以前から「Puppeteerの上位互換」のような評価を目にしていて、試したかったためです。目的さえ達成できれば、なんでもかまいません。また、言語はPythonとしました。単純に慣れているからで、深い理由はありません。その他、パッケージ管理をどうするかなどの話も、些末なので省きます。Dockerイメージでどこまで処理するか次に、Dockerイメージでどこまで処理するかです。RSSを出力し、S3に保存するところまで任せてよいかもしれません。RSSは使わず、新着情報をSlackに直接ポストしてもよいでしょう。今回は、RSSを標準出力に出力するだけにしました。RSS化すれば、新着情報を場面で活用できます。出力するRSSのS3への保存は、イメージの利用者がすべきだと考え、対象外としました。Dockerイメージをどこで実行するか今回いちばん悩んだのが、Dockerイメージをどこで実行するかです。CodeBuildのほかにも、AWS Lambda、Amazon ECSといった選択肢があります。結局CodeBuildにしたのは、AWS LambdaではPlaywightがうまく動かせず、また、ECSのためだけにVPCを作るのは手間だったからでした。CodeBuildだと、ローカルと同じようにイメージがすんなり実行できました。DockerイメージをどうビルドするかDockerイメージをどうビルドするかについても、少し悩みました。Docker Build Cloudでなくても、CodeBuildでも、GitHub Actionsでも、なんでもよいといえばよいのです。先んじて、チームメンバーの深堀さんがDocker Build Cloudを検証されていたので、今回はそれに乗っかってみました。実際、マルチアーキテクチャなイメージがさくっと作れたので、今後も積極的に使うつもりです。tech.enechange.co.jpSlackにRSSをどう連携するか最後に、SlackにRSSをどう連携するかです。IFTTTを使わずとも、SlackのRSSアプリでも通知できます。今回、IFTTTを選んだのは、通知メッセージをカスタマイズしたいとのリクエストがあったためでした。また、すでに有料プランを契約している背景もありました。おわりに以上、同僚からの「弊社Webページの新着情報をSlackに通知したい」との相談に、ぼくがどのように対応したかご紹介しました。ちょっとした相談でしたが、PlaywrightやDocker Build Cloudといった未経験の技術にふれるきっかけとなってよかったです。VPoTのぼくだからではなく、ENECHANGEでは誰でも裁量広く動けるので、試してみたい技術を気軽に試せます。広い裁量で学びつつ仕事したい方、ENECHANGEの採用サイトをぜひご覧ください。engineer-recruit.enechange.co.jpおまけ：サンプルコードせっかくなので、サンプルコードを載せておきます。いずれもMITライセンスです。ご利用になる場合は、当然ながら自己責任でお願いします。DockerfileARG SCRIPT_DIR="/script"ARG PLAYWRIGHT_BROWSERS_PATH=${SCRIPT_DIR}/browsersFROM python:3.12 as build-imageARG SCRIPT_DIRARG PLAYWRIGHT_BROWSERS_PATHENV PLAYWRIGHT_BROWSERS_PATH=${PLAYWRIGHT_BROWSERS_PATH}WORKDIR ${SCRIPT_DIR}COPY requirements.txt ${SCRIPT_DIR}RUN pip install --target ${SCRIPT_DIR} -r requirements.txt --no-cache-dirRUN python -m playwright install chromiumFROM python:3.12-slimARG SCRIPT_DIRARG PLAYWRIGHT_BROWSERS_PATHENV PLAYWRIGHT_BROWSERS_PATH=${PLAYWRIGHT_BROWSERS_PATH}RUN apt-get update && apt-get install -y --no-install-recommends \    libglib2.0-0 \    libnss3 \    libnspr4 \    libdbus-1-3 \    libatk1.0-0 \    libatk-bridge2.0-0 \    libcups2 \    libdrm2 \    libatspi2.0-0 \    libx11-6 \    libxcomposite1 \    libxdamage1 \    libxext6 \    libxfixes3 \    libxrandr2 \    libgbm1 \    libxcb1 \    libxkbcommon0 \    libpango-1.0-0 \    libcairo2 \    libasound2 \    && apt-get clean \    && rm -rf /var/lib/apt/lists/*WORKDIR ${SCRIPT_DIR}COPY --from=build-image ${SCRIPT_DIR} ${SCRIPT_DIR}COPY generate_rss.py ${SCRIPT_DIR}CMD [ "/usr/local/bin/python", "generate_rss.py" ]generate_rss.pyimport osfrom bs4 import BeautifulSoupfrom datetime import datetimefrom feedgen.feed import FeedGeneratorfrom playwright.sync_api import sync_playwrightdef get_page_content(url):    with sync_playwright() as playwright:        with playwright.chromium.launch(headless=True) as browser:            with browser.new_page() as page:                page.goto(url)                content = page.content()                return contentdef generate_rss(title, description, url, content):    fg = FeedGenerator()    fg.title(title)    fg.link(href=url, rel="alternate")    fg.description(description)    soup = BeautifulSoup(content, "html.parser")    ul = soup.find("ul", class_="news")    for li in ul.find_all("li", recursive=False):        title = li.find("span", class_="title").text        link = li.find("a")["href"]        category = li.find("span", class_="category").text        pub_date_str = li.find("span", class_="date").text        pub_date = datetime.strptime(pub_date_str + "+0900", "%Y/%m/%d%z")        fe = fg.add_entry()        fe.title(title)        fe.link(href=link)        fe.category({"term": category})        fe.pubDate(pub_date)    return fg.rss_str(pretty=True).decode("utf-8")if __name__ == "__main__":    target_url = os.environ["TARGET_URL"]    content = get_page_content(target_url)    rss_title = os.environ["RSS_TITLE"]    rss_description = os.environ["RSS_DESCRIPTION"]    rss = generate_rss(rss_title, rss_description, target_url, content)    print(rss)requirements.txtbeautifulsoup4feedgenplaywright

動的Webページの新着情報をどうSlackに通知するか

Docker Build Cloudを本番CI/CDパイプラインに導入・検証してみた

VPoTの岩本 (iwamot) と申します。このブログを含め、AWSについてのアウトプットが好きで続けていたら、先日 AWS Community Builder (Cloud Operation) に選んでいただけました。これを励みに、さらにアウトプットしていきます。ところで、SRE Magazineという、株式会社MIXIの井上さんが発刊準備を進められているWeb雑誌があり、ぼくも寄稿できないかネタを考えていたところ「非常時の可用性をフィーチャーフラグで保つアイディア」が思いつきました。アイディアの詳細は発刊をお待ちいただくとして（追記：発刊されました！）、AWSでフィーチャーフラグといえばAppConfigなので、ENECHANGEでもAppConfigが活用できそうか、試してみることにしました。ぼくもENECHANGEも、AppConfigは未経験だったのです。ECSで簡単に使える！まず気になったのは、ENECHANGEでよく使っているECSで、AppConfigの設定データが簡単に参照できるかどうかでした。この点は、AppConfigエージェントコンテナをサイドカーとしてタスクに含めることで、他のコンテナからHTTPで参照できることがドキュメントですぐに分かりました。また、実際にECSタスクを作り、下記の動作を確認しました。Webコンテナから設定データが参照できることAppConfig側で新たな設定データをデプロイし、しばらくすると（エージェントのポーリング間隔を待つと）Webコンテナから新たな設定データが参照できることアプリケーションの再デプロイをすることなく、短い時間で設定データを変えられるので、非常時をはじめとして、使いどころが色々ありそうに感じます。ローカルでの開発も簡単！次に気になったのはローカルでの開発です。App Configの設定データによって処理を分岐するのが一般的な使い方でしょうから、ローカルでの開発時にも設定データを切り替えてテストしたくなるはずです。この点も考えられていて、エージェントのイメージで LOCAL_DEVELOPMENT_DIRECTORY 環境変数を指定し、そのディレクトリの所定のパスに設定データを置くことで、ECS環境と同じような感覚で参照したり切り替えたりできるようになっています。サンプルをGitHubに置いたので、ご興味のある方はお試しください。github.com結論、ばっちり活用できそうということで、ECSで運用するアプリケーションにおいては、ばっちり活用できそうな印象でした。ENECHANGEでは、社内製のTerraformモジュールでECS環境を管理しているため、そのモジュールに手を入れる形で、AppConfigを簡単に使えるようにしていきたいと思っています。こんな楽しい仕事ができるポジション、募集中ですさて、ぼくがマネージャーを務めているCTO室は、日々こんな感じで、便利そうな機能やサービスを試しては、事業部に導入を提案しています。楽しくて仕方ありません。こんな楽しい仕事ができるポジションに、まだ空きがあります。下記エンジニア採用サイトの「事業部を問わない求人 > SRE」です。ご興味のある方、ぜひご覧ください🙏engineer-recruit.enechange.co.jp

AWS AppConfigが活用できそうか試してみました

VPoTの岩本 (iwamot) です。2024-03-02に、AWSのユーザーコミュニティによる大規模イベント、JAWS DAYS 2024が開催されました。jawsdays2024.jaws-ug.jpENECHANGEは企業サポーターとして、ぼく自身も個人サポーターとして、このイベントに参加しました。9時の入場から19時半の退場まで、すべてのことが楽しかったのですが、なかでも楽しかった5つのことを、思い出しながらまとめてみます。サンプリングスペースの設営が楽しかった企業サポーターに与えられたサンプリングスペースに、弊社グッズをどう配置するか考えるのが、まず楽しい経験でした。事前に社内Slackでグッズを募ったところ、EV充電サービス事業部からキャンディ・ステッカー・カードを提供してもらえることになりました。イベント前日にはオフィスでグッズを受け取り、会場近くの100円ショップでカゴを調達しました。入場後にグッズを並べてみて、調達したカゴのサイズ感が最高だったので、それだけでテンションが上がった次第です。EV充電サービスはエンジニア特化ではないため、参加者のみなさまにグッズをお持ちいただけるのか不安でしたが、杞憂でした。たとえばキャンディは撤収時には3分の1になっていました。お取りいただいた方、ありがとうございました。スタンプラリーが楽しかったスタンプラリー企画も楽しみで、11時過ぎにはコンプリートしました。登壇前にスタンプラリー終えられた！ #jawsdays2024 #jawsug pic.twitter.com/YCYEVCdgxY— Takashi Iwamoto (@iwamot) 2024年3月2日   11時45分には登壇準備が始まるため、それまでに回りたいなと思っていたのです。この調子で、5冠にとどまっているAWS認定もコンプリートしたい所存です。登壇が楽しかったぼくにとってのメインイベント、ランチセッションでの登壇も楽しい経験でした。弊社の協賛したランチサポーターは、15分の登壇枠をいただけたのです。今回ぼくは「【A-3】サービスクォータ、ちゃんと監視してますか？」セッションにて、タイトルどおりサービスクォータ監視の重要性についてお話ししました。 speakerdeck.comみなさんランチに夢中なのではないかと心配でしたが、思ったより多くの方に聴いていただけ、とてもうれしく感じております。お聴きいただいたみなさま、また、現地で応援してくれた同僚各位、ありがとうございました。セッションが楽しかった登壇後は肩の力を抜いて、下記のセッションに参加して楽しみました。【E-6】生成AIで社内文書検索！Bedrockの新機能でRAGアプリを簡単に作ってみよう【A-10】技術書を書く技術：あなたの知識を世界に届けよう！！【A-11】AWSセンセーション 私とみんなが作ったAWSセキュリティいずれのセッションも「そりゃ採択されるよな～」という知見やサービス精神に満ちた内容で、参加者としても、登壇者のはしくれとしても、とても参考になりました。懇親会が楽しかったそして懇親会も、最後まで楽しみました。表彰される方々や、スタンプラリー企画の抽選に当たった方々を、うらやましくながめつつ、ビールを傾けておりました。他のイベントでお会いしたことのある方、SNSでだけやりとりしていた方、仕事でお世話になっているAWSの方など、いろいろな方にごあいさつもできました。残念ながらごあいさつできなかった方は、次回よろしくお願いします。おわりにというわけで、JAWS DAYS 2024に参加して楽しかった5つのことを、企業サポーターかつ個人サポーターの目線でまとめてみました。サンプリングスペースの設営が楽しかったスタンプラリーが楽しかった登壇が楽しかったセッションが楽しかった懇親会が楽しかったあまりに楽しかったので、懇親会で告知された10月の「JAWS FESTA 2024 in Hiroshima」も、ホテルと交通手段を予約してしまいました。人はこうして沼にハマっていくのでしょう。関係者のみなさま、参加者のみなさま、本当にありがとうございました。広島でもお会いしましょう。

ENECHANGE Developer Blog

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

ALB脆弱性の影響と対策

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

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

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

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

ENECHANGEの新たな取り組みI/O Dayとは？技術革新の現場をインタビュー！

最近遭遇した useEffect のアンチパターンを紹介【React】

インターン生として半年間ENECHANGEで働いてみて

事業譲渡を受けたアプリとの統合で失敗、そしてユーザーからの評価回復に至るまで

AIレビューツールであるCodeRabbitを試してみました【設定ファイルあり】

メリットだらけなので、AWSパートナーになりました

Rails + Hotwire を試してみて、使いどころを考えてみた

100以上のLLMが使えるSlackbot OSS、Collmboを公開しました

JaSST'24 Tohokuに参加してきました！〜テスト技法編〜

RubyKaigi 2024 に参加してきました！

MySQLパフォーマンス向上のためのプロビジョニングIOPSの活用とその結果

Amazon AppFlowをGA4に接続し、人気記事ランキングをSlackに自動投稿する

カスタマーサービスセンターの新拠点のネットワーク調査

音声認識モデルの精度を検証

Slackのfiles.upload API廃止に備え、Google Apps Scriptのコードに手を入れる

Easy-RSAで作成したサーバ・クライアント証明書をAWSで利用する

オールチームで進めよう！〜AWS Transit Gatewayによるコスト削減事例〜

事業を支えるSREのノウハウを共有！ ENECHANGE主催イベント・レポート

Team Blog HubをVercelからCloudflare Pagesに移行しました

AWS Chatbotの現行仕様に耐えつつ、EC2インスタンスの状態をSlackで一覧表示する

動的Webページの新着情報をどうSlackに通知するか

Docker Build Cloudを本番CI/CDパイプラインに導入・検証してみた

AWS AppConfigが活用できそうか試してみました

JAWS DAYS 2024に参加して楽しかった5つのこと

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

ALB脆弱性の影響と対策

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

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

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

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

ENECHANGEの新たな取り組みI/O Dayとは？ 技術革新の現場をインタビュー！

最近遭遇した useEffect のアンチパターンを紹介 【React】

インターン生として半年間ENECHANGEで働いてみて

事業譲渡を受けたアプリとの統合で失敗、 そしてユーザーからの評価回復に至るまで

AIレビューツールであるCodeRabbitを試してみました【設定ファイルあり】

メリットだらけなので、AWSパートナーになりました

Rails + Hotwire を試してみて、使いどころを考えてみた

100以上のLLMが使えるSlackbot OSS、Collmboを公開しました

JaSST'24 Tohokuに参加してきました！〜テスト技法編〜

RubyKaigi 2024 に参加してきました！

MySQLパフォーマンス向上のためのプロビジョニングIOPSの活用とその結果

Amazon AppFlowをGA4に接続し、人気記事ランキングをSlackに自動投稿する

カスタマーサービスセンターの新拠点のネットワーク調査

音声認識モデルの精度を検証

Slackのfiles.upload API廃止に備え、Google Apps Scriptのコードに手を入れる

Easy-RSAで作成したサーバ・クライアント証明書をAWSで利用する

オールチームで進めよう！ 〜AWS Transit Gatewayによるコスト削減事例〜

事業を支えるSREのノウハウを共有！ ENECHANGE主催イベント・レポート

Team Blog HubをVercelからCloudflare Pagesに移行しました

AWS Chatbotの現行仕様に耐えつつ、EC2インスタンスの状態をSlackで一覧表示する

動的Webページの新着情報をどうSlackに通知するか

Docker Build Cloudを本番CI/CDパイプラインに導入・検証してみた

AWS AppConfigが活用できそうか試してみました

JAWS DAYS 2024に参加して楽しかった5つのこと

ENECHANGEの新たな取り組みI/O Dayとは？技術革新の現場をインタビュー！

最近遭遇した useEffect のアンチパターンを紹介【React】

事業譲渡を受けたアプリとの統合で失敗、そしてユーザーからの評価回復に至るまで

オールチームで進めよう！〜AWS Transit Gatewayによるコスト削減事例〜