やってたこと 2024/07
7/1(月) - 7(日)
とあるサービスクローズメンテナンスの大苦戦
CloudFornt をちゃっ、と切り替えて終わりだろ、って思ってたメンテナンスがなんと徹夜作業になった
敗因は
- クローズする方の CloudFront の alias DNS は先に撤去が必要
- 少し停止時間が発生する
- なぜか切り替え後に Mixed Content となってしまい、WordPress のカスタマイズで解決してもらった
- 検証不足
- WordPress管理画面にアクセスできなくなってしまって、復旧に苦戦
- これも検証不足、というか確認項目に入れてなかった
- CloudFront のキャッシュ設定を調整することで解決した模様
- 自分は限界で、「寝てた」
この週のいろいろに影響を残してしまい、最悪の滑り出しとなった
RDS 証明書更新
夜中にシュッとやった。マネコン操作。
MariaDB レプリケーション切れ
なかなかのレガシープロダクト、とある日に表示される数値がなにもかも 0 という問題が発生。
午後から稼働、という日に、午前から作業することとなった。月曜のこともあって、調子がよくないという中。
この問題の対処も、「見てるだけ」だったが、"障害だ〜" って叫ぶ(?)のだけはやった。
POSITION をどうのこうのして、復旧。
ほんとに、"先達はあらまほしき事なり"。
前日アラート上がってたね、とか、いろいろ反省点はある。
マネージドサービスに浸かりきっていた今日びに、目の覚めるような出来事だった。
初・Aurora S3 Export
S3 バケットを作り、IAM Role を準備して、RDS 管理画面からぽちっとした。
Terraform でも作れるんですね、というのは初回Export直後に把握した。
Aurora S3 Export
の定期実行を翌々週に組んだ。
IAMの設定がまあまあいろいろ足さないとなんだな、というのと、CloudWatch Logs にログを出せない(?)ようなので、CloudWatch Mertics で Invoke したのと Error になったのしかわからなくて少々難儀した。
S3Prefix に関して
x "rds-exports/${formatdate("YYYYMMDD", timeadd(timestamp(), "9h"))}"
o "rds-exports/${formatdate("YYYY/MM/DD", timeadd(timestamp(), "9h"))}"
なのがちょっと良くワカラナかった
実はまだうまくいってない。S3Prefix の話、 o のも実は x で、とある日のほぼ手動での初回実行が成功する、というだけだった。動的に「その日」の ExportTaskIdentifier を生み出すにはどうすればいいのだろうか。
試行中の HCL コード
resource "aws_scheduler_schedule_group" "rds_to_bq" {
name = local.rds_to_bq_group_name
}
resource "aws_scheduler_schedule" "rds_export_to_s3" {
name = local.rds_export_to_s3_task_name
group_name = local.rds_to_bq_group_name
flexible_time_window {
mode = "OFF"
}
state = "DISABLED"
schedule_expression = "cron(00 0 * * ? *)"
schedule_expression_timezone = "Asia/Tokyo"
target {
arn = "arn:aws:scheduler:::aws-sdk:rds:startExportTask"
role_arn = aws_iam_role.event_bridge_scheduler.arn
input = jsonencode({
//ExportTaskIdentifier = var.export_task_identifier
ExportTaskIdentifier = "daily-export-${formatdate("YYYY-MM-DD", timeadd(timestamp(), "9h"))}"
SourceArn = data.terraform_remote_state.storage_rds.outputs.db_cluster_arn
IamRoleArn = data.terraform_remote_state.iam_role_aurora_export_to_s3.outputs.aurora_export_to_s3_role_arn
KmsKeyId = data.terraform_remote_state.storage_kms.outputs.kms_key_arn
S3BucketName = data.terraform_remote_state.storage_s3.outputs.s3_export_store_bucket_id
S3Prefix = "rds-exports/${formatdate("YYYY/MM/DD", timeadd(timestamp(), "9h"))}"
//S3Prefix = var.s3_prefix_format
})
}
}
variable "export_task_identifier" {
description = "The export task identifier format"
default = "daily-export-<aws.scheduler.current-date:YYYY-MM-DD>"
//default = "daily-export-$.scheduler.currentDate"
}
variable "s3_prefix_format" {
description = "The S3 prefix format"
default = "rds-exports/<aws.scheduler.current-date:YYYY>/<aws.scheduler.current-date:MM>/<aws.scheduler.current-date:DD>"
//default = "rds-exports/$.scheduler.currentDate:YYYY/$.scheduler.currentDate:MM/$.scheduler.currentDate:DD"
}
↑見たり(ちゃんと読み込んではいないのだが)、AI と問答したりしているが、サポートに聞くしかないかなあ、と思ってたり、デイリーで自動で terraorm apply してあげるとかしないとダメなのか?と思ったりしている。
サポートに聞いたら、EventBridge -> Lambda -> StartExportTask って流れにして、とのことだったので、TypeScript で Lambda を仕込んでいく・・・(8月につづく)
7/8(月) - 15(月祝)
HAproxy + keepalived で冗長化
HAProxy の backend に対するフェールオーバー・フェールバックは把握できた。
HAProxy 自身のフェールオーバーはわかったんだが、フェールバックをまだ把握できてない。
時間がややなくなってきてるので、突き進むことにして AlmaLinux 9 の VM を構築し始めて、backend の Apache に疎通確認までをやった。
iptables とかひっさびさに弄った。
初・Athena で アクセスログ検索
TABLE は作らなきゃなんですね。apache の conf から Format を https://www.perplexity.ai/ に「食わせる」と CREATE TABLE 作ってくれるの便利。
S3 にあるログファイルが謎フォーマットになっていて、検索ができねえ・・・
=> いろいろ調べた結果、謎が解けた。
- CloudWatch Logs -> (サブスクリプションフィルター) -> Amazon Data Firehose で S3 に放り込まれていた
- S3 に放り込まれていたログファイルは gzip 圧縮されたテキストファイル
- 拡張子 .gz をマネコンの設定でつけるようにしたら Athena で解析できるようになった
謎のクライアントTLSネゴシエーションエラー多発
ALBのコスト、せいぜい $3/day くらいだったのが $17/day になってるんだが!?という連絡で発覚。
証明書ポリシー変えるとかしても状況よくならなかったのでシュッとリプレースした。
Aurora Serverless V1 (mysql5.7:Aurora2系) から V2 (mysql8.0:Aurora3系) に上げる手順の調査
- Aurora Serverless V1 は Blue/Green Deployment をサポートしていない
- Aurora Serverless V1 のサポートは 2024年12月31日に終了予定
- 今の Aurora Serverless V1 (mysql5.7:Aurora2系) から mysql8.0:Aurora3系にアップグレードはUIからできない
ようなので、「どう上げていけばいいの?」をいろいろな手段で調べた。
- Aurora Serverless V2 もしくは Aurora RDS のクラスターを作成し、dump -> restore で現状のデータを移行(5.7:Aurora2)<- これから作成できるのか?
- 移行した Aurora Serverless V2 もしくは Aurora RDS を Blue/Green Deployment でアップグレード
を想定して、こんな感じですかね?と聞いたら、プロビジョニング済みに変換する
っていうのがあることを聞いた。AWS CLI でやるらしい。
Aurora Serverless v1 DB クラスターをプロビジョニング済みに変換する - Aurora User Guide
そうすると、Blue/Green Deployment で上げられるとのこと。
なお、プロビジョニング済みに変換する
で発生するダウンタイムは30秒ほどらしい。凄いな(これだけでアップグレードできるなんて)
AWS Config でのリソース作成検知がうまくいかない
一度はうまくいったと思ってたのだが、無駄な通知を抑制してたらなにもかもがうまくいかなくなっていて、別の機会にやり直しそう。リセットしたら、という感じ。
7/16(火) - 21(日) - 31(水)
aarch64 の Mac を前提とした環境が起動しなかった謎
解決はしたが、x86_64
と解釈されてたのが原因っぽい。ひとまず arm64
を強制指定して回避
→ 違った。arm64
条件になぜかHitしなくて amd64
になってた。 arm64
で固定して回避、だったような。
キュラーズに初荷物投入
暑かったのと、用意してもらってるワゴン、逆にいらないな・・・となった。
次回、どかしてもらおうかな・・・
Bitbucket でカスタムマージチェックアプリを作った
Forge App というらしい
ある制約下における compose 環境の調整試行
stancl/tenancy
を利用した Laravel アプリのマルチテナント化(?) に挑んだのですが、ローカル環境を hosts で localhost を dev.hoge.local
のようなホスト名にして動かすのにかなり苦戦した。
フロントエンド(Nuxt.js)の画面からバックエンド(Laravel)のAPIに疎通しなくて、perplexity.ai にいろいろ聞いて対策を試みた。結果、
extra_hosts:
- "dev.hoge.local:host-gateway"
というような指定などで疎通できた。(要因これだけなのかは掘りきれてない)
URL::forceScheme('https'); の話
Teammate が難儀してた話なんですが、とある Laravel アプリケーションで、ECS環境でだけ表示がおかしいという状況(7月頭から、たくさん出会ったような気がする・・・)があって、URL::forceScheme('https');
を追加することで解決したらしい。
過去の自分の対応でも、↓のような実装を追加していたというメモが残っていた。
if (! App::environment('local')) {
URL::forceScheme('https');
}
改めて、覚えておこう、と思ったので書いておく。
CodePipeline 量産体制
Jenkins に載せてたデプロイ機構を CodePipeline に載せ替えていくマンになる。8月。
ある制約下における compose 環境の調整試行
の続き
DBにかなり強力な(WITH GRANT OPTION)権限付与しないと、domain.add が走らなかったし、
フロントエンドのドメインじゃなくてバックエンドのドメインをテナントのドメインにしないと API が期待動作しなかった。
とりあえず、ログインまではできた・・・(これも、8月に続く)