Zenn
Closed7

やってたこと 2024/07

MySQL
WordPress
CloudFront
haproxy
sogaohsogaoh

7/1(月) - 7(日)

とあるサービスクローズメンテナンスの大苦戦

CloudFornt をちゃっ、と切り替えて終わりだろ、って思ってたメンテナンスがなんと徹夜作業になった
敗因は

  1. クローズする方の CloudFront の alias DNS は先に撤去が必要
    • 少し停止時間が発生する
  2. なぜか切り替え後に Mixed Content となってしまい、WordPress のカスタマイズで解決してもらった
    • 検証不足
  3. WordPress管理画面にアクセスできなくなってしまって、復旧に苦戦
    • これも検証不足、というか確認項目に入れてなかった
    • CloudFront のキャッシュ設定を調整することで解決した模様
      • 自分は限界で、「寝てた」

この週のいろいろに影響を残してしまい、最悪の滑り出しとなった

RDS 証明書更新

夜中にシュッとやった。マネコン操作。

MariaDB レプリケーション切れ

なかなかのレガシープロダクト、とある日に表示される数値がなにもかも 0 という問題が発生。
午後から稼働、という日に、午前から作業することとなった。月曜のこともあって、調子がよくないという中。

この問題の対処も、「見てるだけ」だったが、"障害だ〜" って叫ぶ(?)のだけはやった。
POSITION をどうのこうのして、復旧。

ほんとに、"先達はあらまほしき事なり"。

前日アラート上がってたね、とか、いろいろ反省点はある。

マネージドサービスに浸かりきっていた今日びに、目の覚めるような出来事だった。

初・Aurora S3 Export

S3 バケットを作り、IAM Role を準備して、RDS 管理画面からぽちっとした。
https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/export-cluster-data.html

Terraform でも作れるんですね、というのは初回Export直後に把握した。
https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/rds_export_task

sogaohsogaoh

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"))}"
なのがちょっと良くワカラナかった

sogaohsogaoh

実はまだうまくいってない。S3Prefix の話、 o のも実は x で、とある日のほぼ手動での初回実行が成功する、というだけだった。動的に「その日」の ExportTaskIdentifier を生み出すにはどうすればいいのだろうか。

試行中の HCL コード
event-bridge.tf
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"
}

https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-transform-target-input.html#eb-transform-input-examples
↑見たり（ちゃんと読み込んではいないのだが）、AI と問答したりしているが、サポートに聞くしかないかなあ、と思ってたり、デイリーで自動で terraorm apply してあげるとかしないとダメなのか？と思ったりしている。

sogaohsogaoh

サポートに聞いたら、EventBridge -> Lambda -> StartExportTask って流れにして、とのことだったので、TypeScript で Lambda を仕込んでいく・・・（8月につづく）

sogaohsogaoh

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 作ってくれるの便利。
https://repost.aws/ja/knowledge-center/analyze-logs-athena

S3 にあるログファイルが謎フォーマットになっていて、検索ができねえ・・・
=> いろいろ調べた結果、謎が解けた。

  • CloudWatch Logs -> (サブスクリプションフィルター) -> Amazon Data Firehose で S3 に放り込まれていた
  • S3 に放り込まれていたログファイルは gzip 圧縮されたテキストファイル
  • 拡張子 .gz をマネコンの設定でつけるようにしたら Athena で解析できるようになった

謎のクライアントTLSネゴシエーションエラー多発

ALBのコスト、せいぜい $3/day くらいだったのが $17/day になってるんだが！？という連絡で発覚。
証明書ポリシー変えるとかしても状況よくならなかったのでシュッとリプレースした。

https://x.com/sogaoh/status/1811447430401163446

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からできない

ようなので、「どう上げていけばいいの？」をいろいろな手段で調べた。

  1. Aurora Serverless V2 もしくは Aurora RDS のクラスターを作成し、dump -> restore で現状のデータを移行（5.7:Aurora2）<- これから作成できるのか？
  2. 移行した Aurora Serverless V2 もしくは Aurora RDS を Blue/Green Deployment でアップグレード

を想定して、こんな感じですかね？と聞いたら、プロビジョニング済みに変換する っていうのがあることを聞いた。AWS CLI でやるらしい。

Aurora Serverless v1 DB クラスターをプロビジョニング済みに変換する - Aurora User Guide
https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/aurora-serverless.modifying.html#aurora-serverless.modifying.convert

そうすると、Blue/Green Deployment で上げられるとのこと。
なお、プロビジョニング済みに変換する で発生するダウンタイムは30秒ほどらしい。凄いな（これだけでアップグレードできるなんて）

AWS Config でのリソース作成検知がうまくいかない

一度はうまくいったと思ってたのだが、無駄な通知を抑制してたらなにもかもがうまくいかなくなっていて、別の機会にやり直しそう。リセットしたら、という感じ。

sogaohsogaoh

7/16(火) - 21(日) - 31(水)

aarch64 の Mac を前提とした環境が起動しなかった謎

解決はしたが、x86_64 と解釈されてたのが原因っぽい。ひとまず arm64 を強制指定して回避
→ 違った。arm64 条件になぜかHitしなくて amd64 になってた。 arm64 で固定して回避、だったような。

キュラーズに初荷物投入

暑かったのと、用意してもらってるワゴン、逆にいらないな・・・となった。
次回、どかしてもらおうかな・・・

Bitbucket でカスタムマージチェックアプリを作った

https://support.atlassian.com/ja/bitbucket-cloud/docs/set-up-and-use-custom-merge-checks/

Forge App というらしい

ある制約下における compose 環境の調整試行

stancl/tenancy を利用した Laravel アプリのマルチテナント化(?) に挑んだのですが、ローカル環境を hosts で localhost を dev.hoge.local のようなホスト名にして動かすのにかなり苦戦した。
フロントエンド(Nuxt.js)の画面からバックエンド(Laravel)のAPIに疎通しなくて、perplexity.ai にいろいろ聞いて対策を試みた。結果、

compose.yml

    extra_hosts:
        - "dev.hoge.local:host-gateway"

というような指定などで疎通できた。（要因これだけなのかは掘りきれてない）

URL::forceScheme('https'); の話

Teammate が難儀してた話なんですが、とある Laravel アプリケーションで、ECS環境でだけ表示がおかしいという状況（7月頭から、たくさん出会ったような気がする・・・）があって、URL::forceScheme('https'); を追加することで解決したらしい。

過去の自分の対応でも、↓のような実装を追加していたというメモが残っていた。

起動周りで通るやつ.php(...)

        if (! App::environment('local')) {
            URL::forceScheme('https');
        }

改めて、覚えておこう、と思ったので書いておく。

CodePipeline 量産体制

Jenkins に載せてたデプロイ機構を CodePipeline に載せ替えていくマンになる。8月。

sogaohsogaoh

ある制約下における compose 環境の調整試行 の続き

https://x.com/sogaoh/status/1817610207494885515

DBにかなり強力な（WITH GRANT OPTION）権限付与しないと、domain.add が走らなかったし、
フロントエンドのドメインじゃなくてバックエンドのドメインをテナントのドメインにしないと API が期待動作しなかった。
とりあえず、ログインまではできた・・・（これも、8月に続く）

このスクラップは4ヶ月前にクローズされました