AWSのログ管理についてはいくつか考えるポイントがあると思います。
などなど。
システムの特性によるところも多いかと思いますが、自分の中でのログ管理のベースラインが定まりつつあるので、頭の整理がてらまとめます。
自分の中での大まかな方針としては以下です。
全体像としては以下になります。
なおあくまで個人的な経験に基づくものなので、実際にはシステムの特性を踏まえて方針の決定が必要かと思います。 またこれは必要、これは不要などご意見あればいただけると非常に嬉しいです。
タイトルの通りですが、AWS CDKを使い始めてからAWS CodeBuildのbuildspecはBuildSpec.fromObjectを使って生成しています。
個人的にはbuildspecの管理がかなり便利だと思っているので、簡単にまとめます。
続きを読むAmazon AthenaにPartition Projection（パーティション射影）という機能があります。
ざっくりいうとパーティション管理を自動化して、高速にクエリが実行でき、お財布にも優しいというものです。個人的にはめちゃくちゃ便利だなと思い、特にログの調査に活用しています。
ログ調査対象のサービスの内、大体どのプロジェクトでも使っているものがいくつかあります（ALB、VPCフローログ、CloudTrail....）。
これまではPartition Projectionの設定を行うCREATE文を毎回実行していたのですが、少し面倒なのでAWS CDKで実装し使いまわせるようにしました。
今回の実装の全体像は以下です。
CDKでECSのタスク定義を作成すると、必ず遭遇する（と思う）コンテナのイメージタグがCDKと実態でズレる問題への対応についてです。
以下のスライドでまさに言及されているものです。
過去試行錯誤したので、自分なりに整理してみます。
続きを読む本ブログでは何回かAWS CDKで構築したAurora（RDS）クラスターを運用の観点で検証してきました。
当たり前ですがCDKで作ったとしても、そのあとは運用を行っていく必要があるので、運用継続ができるかは重要かと思います。特にDB（ステートフルなリソース）は扱いが難しいため、さまざまな検証をしています。
今回はAmazon RDS Blue/Green Deployments（以降B/G デプロイと記載）が題材です。
B/GデプロイはCloudFormation（CDK）非対応なので、マネコン等からの操作を行う必要があります。そのため実施するとCDKの実装と実態が必ず乖離します。
今回はAWS CDKで作ったAuroraクラスターに対してB/G デプロイを行い、その後CDKと実態を一致させることで運用継続ができるのかを検証します。
先に結論を記載すると、「できなくはないが、CDKと実態を一致させる際にクラスターの再起動が行われる可能性がある」です。
続きを読むリージョン間フェイルオーバーを行うため、Auroraグローバルデータベースを検討することはあるかと思います。
※Aurora グローバルデータベース：リージョン間でデータをレプリケートし、リージョンを跨って運用するための仕組み。
https://pages.awscloud.com/rs/112-TZM-766/images/ORL-T4-Session.pdf
Primaryのリージョンを切り替える際に当然フェイルオーバー操作が発生します。このフェイルオーバー操作がIaCとはなんとも相性が悪そうです。
今回はAWS CDKでAuroraグローバルデータベースを構築したとして、フェイルオーバー発動後にCDKの設定変更反映など運用継続ができるのか？を検証してみました。
結論としては「運用可能」と思われます。以下詳細が続きます。
続きを読む