S3バケットの設定でEventBridgeにイベントを通知する設定が有効になってるか確認しような。。。。。
これをやるのを忘れてて、なんでイベント飛ばないんだ!!!!!とはまってました。
EventBridge完全理解した
— masasuzu (@masasuz) 2022年9月23日
今日もまたVSCodeのタイムラインに救われてしまった
VSCodeにはタイムラインという履歴管理機能?があってこれが便利。gitの履歴とは別にファイルの変更履歴を取っていて、うっかりcommit せずに消してしまった箇所を復活させたりするのに役立ちます。
デフォルトだと左下あたりにこっそりいるはず。
タイムラインの表示はこんな感じ。ここで変更を選択するとdiff形式でエディター画面に表示されます。
今日もタイムラインに救われました
terraformでCloudSQLのインスタンス作成に失敗した
こんなエラーが出てインスタンス作成に失敗した。
╷
│ Error: Error, failed to create instance because the network doesn't have at least 1 private services connection. Please see https://cloud.google.com/sql/docs/mysql/private-ip#network_requirements for how to create this connection.
│
│ with google_sql_database_instance.primary,
│ on database.tf line 1, in resource "google_sql_database_instance" "primary":
│ 1: resource "google_sql_database_instance" "primary" {
│
╵
terraformのコードとしてはこれ。原因としては、private_networkの指定が間違っていた。
resource "google_sql_database_instance" "primary" {
name = var.database.primary.name
project = var.project_id
region = var.database.primary.location
database_version = var.database.primary.version
settings {
tier = var.database.primary.tier
availability_type = var.database.primary.availability_type
disk_size = var.database.primary.disk_size
ip_configuration {
ipv4_enabled = false
private_network = var.database.private_network # <= これ
}
backup_configuration {
enabled = true
binary_log_enabled = true
}
}
deletion_protection = "true"
}
エラーメッセージにネットワーク名が出てればすぐ原因にたどり着けたのに。。。無駄な時間をかけてしまった。
会社辞めました
近況報告です。
ということで、物理出社はしていませんが最終出勤日でした。
— masasuzu (@masasuz) 2022年4月11日
お世話になりました。
4月末まで｢無職｣になります。
5/1から新しい会社に勤めることになります。職種は一応SREです。
奇特な方はいらっしゃらないとは思いますが、様式美なので置いておきます。
有給休暇消化期間ですが、案外忙しいです。。。。。
読みたい技術書というか、読まなければいけないものが10冊くらい溜まってるけど、有給休暇消化期間中に読み終えられるかな、、、、、
— masasuzu (@masasuz) 2022年4月14日
アプリケーションをメンテナンスモードにする方法について考えるメモ
前提
構成要素
- ALB
- ECS上でうごいているアプリケーション
- CloudWatch Eventのcronで起動するECSスケジュールタスク
- RDSなどのデータストア
現状
terrafromのmaintainance_mode変数を見てtrueであれば、ALBで503を返すようにして、スケジュールタスクを止めるように記述している。
問題
- メンテナンス入れるたびにterrafrom applyをする必要がある
- 管理リソースが多いためterraform applyに時間がかかり、時間通りにメンテナンスの開始終了ができない
案
インフラ側で制御する
LambdaでAWSリソースの設定変更を行う
- 既存のやり方と同じ、設定方法がLambdaに変わっただけ
- terrafromのstateに一時的に差分ができてしまう。
- メンテナンス中にAWSリソースの変更がしにくい
- 既存の方法と同じ
アプリケーション側で制御する
データベースの値を参照する
- DB(もしくはRedis等)に入っている値を参照してメンテナンスモードを切り替える
- DBの値を参照するので即時でメンテナンスに入れることができる
- メンテナンス時にRDSやElastiCacheを変更する際バッティングしてしまう
設定ファイルの値を参照する
- 設定ファイルにメンテナンス時間を記述しておき、アプリケーションはその値を参照してメンテナンスであるかを判断する
- メンテナンス開始の明示的な設定変更が不要であらかじめ設定しておける。
- モノリスなら問題がないが、複数サービス存在する場合は複数箇所に設定を入れる必要がある
- 次善策としてS3に設定を置いておき、それを参照することで設定値は1つにできる。
メンテナンスサービスの値を参照する
- 現在メンテナンス中なのかどうかを返すAPIサービスを作る
- 設定は直書きでも、S3上のファイルでも良い
- Parameter Storeでもいいか
- メンテナンスサービスがキャッシュ、プロキシ的に動くので設定が書かれてるAWSリソースへのリクエスト回数を減らすことができる
- アプリケーションはメンテナンスサービスが返す値をもとにメンテナンスかどうかを判断する。
直接S3やParameterStoreを参照すればいいのでは?
- メンテナンスサービスを設置せずに、各アプリケーションが直接設定が書いてあるリソースにアクセスする
- リクエスト回数が極端に多くなければこれでも
まとまらない
1つの方法が良いというわけではなく、メンテナンス箇所がインフラなのかアプリなのかによって方法を組み合わせなければいけないこともあると思います。ECS サービスの変更であれば、アプリケーションのECSタスクが死んでしまうのでアプリをメンテナンスモードにしても無駄だったりします。そういう場合はインフラ側でメンテに入れる必要があったりします。
適材適所でいいのではないでしょうか?
全然他社事例を調べずに書いてるので、他になにかいい方法があったら追記します。
教科書通りじゃうまくいかない
それはそう。
とはいえ、教科書というかベストプラクティスを当てはめてからうまく行かない部分に対して臨機応変に対応するのが定石ではある。
ベストプラクティスという基礎がないとその先の応用を利かせられないので、真剣に取り掛かりたい技術であれば基礎固めを大事にしていきたいと思ってる。
基礎固めを体系的にできるという意味で資格勉強はかなり優秀。ベンダー資格だとまあまあ受験費が高いという難点を除けば、素晴らしい勉強方法だと自分では思ってる。その辺受験費の会社補助がもっとあるといいのになとは思いつつ。
直近でAWSのネットワークの基礎勉強したいので、4月くらいにAWS Certified Advanced Networking - Specialtyを受けたいなと思ってる。ちょうど参考書出ますしね。
EventBridgeのEventPatternで除外条件をつけたいとき
EventBridgeでECS Taskの終了ステータスが0以外のとき、つまり異常終了したときのイベントを拾うためにrange関数を使いました。
resource "aws_cloudwatch_event_rule" "main" { name = local.name event_pattern = jsonencode( { "detail-type" : [ "ECS Task State Change" ], "source" : [ "aws.ecs" ], "detail" : { "containers" : { "exitCode" : range(1, 256), "lastStatus" : [ "STOPPED" ] } } } ) }
が、よくよくドキュメントを見ると “anything-but” という比較演算子があるので、これを使えば素直に意図を表すことができそうです。
resource "aws_cloudwatch_event_rule" "main" { name = local.name event_pattern = jsonencode( { "detail-type" : [ "ECS Task State Change" ], "source" : [ "aws.ecs" ], "detail" : { "containers" : { "exitCode" : [ { "anything-but" : [0] } ], "lastStatus" : [ "STOPPED" ] } } } ) }
スッキリとした解法を見つけたのでこれで安眠できますね。
terrafromでrange関数使いたい
Answer: 使えます
諸事情でECS Taskが失敗したとき、すなわち終了ステータスが1から255の条件のとき、のCloudWatch Event Ruleを書きたかったのですが、ベタに1から255のリスト書くのはつらすぎるので、range関数もしくは範囲記法ないかなあとググったらすぐ見つかりました。ありがたくrange(1, 256) を使わせていただきます。
というか、このルール自体いけてないのはわかってるんですけどね。。。。
将来どうありたいか
正直言うと将来どうなりたいってビジョンあまりないんですよね。
不確実な時代に生きているので、数年後どんな仕事してるかなんて想像もできない。エンジニアとしてキャリアを積んでいたいなといううっすらとした希望はあります。
どうなりたいかよりはどうしていたいかって希望の方が強くて、そのなかで楽しい開発をしていれればなあと思ってます。
楽しいって何かというと、難しい問題なんですが、本質的じゃないことにわずらされないこと、自分がやりたいことをやれてることこれが大事なんじゃないかなと思います。そのための手段として自分自身の専門性、スペシャリティを伸ばしていきたいと思ってます。
そして、仕事ってもちろん一人だけでやるものではないので、他の職種との相互理解が必要だと思ってて、そのために他職種の専門性にもはみ出す必要があるんじゃないかなと思ってます。もちろん仕事を奪い取る必要はないんですが、簡単なタスクであれば専門外であっても自身で巻き取れるくらいのスキルは身につけていたいなと思います。
例えば、パフォーマンスチューニングしてて、イケてないクエリがわかったとして、アプリケーションコードの修正方法が分からないから、修正依頼を投げるより、自身でアプリケーションコードを直して、レビュー依頼を専門性があるエンジニアに依頼する方がアプリケーションエンジニアのわずらわしさを解消できて楽しくできてる気がしてます。こんなふうに少し自分の領域を越境することで、少し少しのまわりの煩わしさを解消することでみんな楽しく開発することにつながっていくのかなと。
よく言われる言葉だとT字型人材っていうんですかね。でもスキルセットとしてはそういう方向で伸ばしいくことでやりたいことがやりやすくなるのかなって思ってます。
あくまで目的は楽しく開発すること。その手段として、自身の専門性を高めること、周辺分野の専門性にもはみ出すことそういうことかなあ。
文字に書き出したらスッキリした気がするけど、まだちょっと粗いのでどっかでもう一回考えをまとめたい。
