サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
GPT-4o
mazyu36.hatenablog.com
🎄本記事は、AWS CDK Advent Calendar 2023 の 18日目の記事となります AWSのサービスを学ぶときにハンズオンを行うことは多いと思いますが、最近は基本的にCDKで実装しています。 メリットや具体的な流れを簡単にまとめます。 ハンズオンをCDKで実装するようにしている背景 メリット メリット1. 頭に残りやすい メリット2. リソースの削除や再作成が容易 メリット3. コードを再利用できる デメリット デメリット1. マネコン操作より時間がかかる デメリット2. そもそもCDKで実装できない場合がある ハンズオンをCDKで実装するときの流れ 1. 元ネタを探す 「サービス名 + Workshop」でググる AWS Workshops AWS 日本語ハンズオン 2. GitHubでリポジトリを作成する 3. CDKでハンズオンを実装していく 4. READMEにア
概要 ※本記事はAWS CDK Advent Calendar 2022の11日目の記事になります。 qiita.com AWS CDKのチーム開発でCDK Pipelinesを導入しようと思ったが、諦めてCI/CDパイプラインを自作した話をまとめる。 背景 CDK開発にCI/CDパイプラインを導入するモチベーションは色々あるが、個人的には「事故を防ぐ」という点が一番大きいと思う。 CDKのデプロイとしては主に「コマンドを手動実行して直接デプロイ」か「CI/CDパイプラインによるデプロイ」のどちらかを取ることが多いと思う。 しかし、前者の手動実行だとデプロイ時に少なからず事故が起きる。 開発者がコマンドを打ち間違えて意図しない環境にdeployしてしまった 開発者が手元のブランチから開発環境に直接deployしてしまった。しかし実はmainが進んでおり開発環境にデプロイされていたため、de
🎄本記事は、AWS CDK Advent Calendar 2023 の 5日目の記事となります 前回、CloudFormationのGit SyncをCDKで使う方法を紹介しました。 mazyu36.hatenablog.com 今回はこちらを活用して、AWS CDK用のGitOpsパイプラインを組んでみたいと思います。 前提 CloudForrmationのGit Syncってなんだっけ CDKにおけるCIOpsとGitOpsの違い CIOps GitOps CDKのGitOpsの使いどころ Git Syncにおける CDKのGitOpsパイプラインの構築 0. プロジェクト構成 1. CDKプロジェクトの作成およびGit Syncの設定 2. OIDCプロバイダーやIAMロールの作成 3. GitHub Actionsワークフロー定義の作成 トリガー契機および変数 チェックアウト〜
CDKでECSのタスク定義を作成すると、必ず遭遇する(と思う)コンテナのイメージタグがCDKと実態でズレる問題への対応についてです。 以下のスライドでまさに言及されているものです。 AWS CDKでECS on FargateのCI/CDを実現する際の理想と現実 / ideal-and-reality-when-implementing-cicd-for-ecs-on-fargate-with-aws-cdk - Speaker Deck 過去試行錯誤したので、自分なりに整理してみます。 事象の内容 前提 (1). CDKでタスク定義をデプロイ (2). アプリの更新が入り、CICDでタスク定義が更新される (3). CDK上でタスク定義を更新しデプロイ 対応策 1. latestタグを使う 2. CDKは初期生成のみで、更新はマネコン等別で行う。 3. CDK上で変更を加える場合は最新の
はじめに 以下の記事でAWS CDKにおけるチーム開発のフローやテストについて記載した。 mazyu36.hatenablog.com mazyu36.hatenablog.com 今回は実装内容についてチーム内で意識合わせしておいた方が良いと思った点をまとめておく。 はじめに 前提 1. Stackの分割基準 極力Stackを分割しないパターン 共通的に使用するリソースを切り出すパターン Stack間参照を避けられない場合の対応 2. ConstructIdの命名規則 3. リソース名つけるか問題 インフラ担当者以外が参照することが多いリソースは名称をつける 他リソースは自動生成するが、判別するためにタグを付与する 4. 不要なリソース、ログの残存の回避 CloudWatch Logsのロググループ S3バケット KMS CMK おわりに 前提 チーム開発のフローの記事に記載した環境構成
個人的に待ち望んでいた、Step Functionsにおけるエクスポネンシャルバックオフの上限設定や、ジッターの設定が追加されたので試してみました。 2023/9/7のアップデートにおける enhanced error handling で追加されています。 aws.amazon.com 目次 目次 1.そもそもエクスポネンシャルバックオフやジッターとは 2. Step Functionsのアップデート内容の確認 最大遅延 ジッターを追加 3. 動作確認 最大遅延の確認 ジッターの確認 エクスポネンシャルバックオフ&ジッターの確認 AWS CDKの対応状況 終わりに 1.そもそもエクスポネンシャルバックオフやジッターとは 以下のBuilder's Libraryの記事が参考になります。 aws.amazon.com 分散システムにおける処理失敗時などのリトライにおいて、以下の2つのプラクテ
前回以下の監視アラートに関する記事を書きました。(予想以上に反響がありました。ありがとうございます) mazyu36.hatenablog.com 監視アラートの基準はシステム特性によるものの、同じメトリクスを使用する場合は閾値や集計期間がシステムによって違うぐらいで仕組みとしては同じため、なるべく使い回しができるようコード化しておきたいところです。 今回は監視アラートをAWS CDKで実装する方法について簡単にご紹介したいと思います。 ※CDKユーザーの中にはご存じの方も多いかと思いますが、特にメトリクス監視はAWS公式のBLEAにも実装がされており非常に参考になります。本記事においても数多く引用させていただいております。 github.com 目次 目次 実装したいもの (1).各サービスから収集したメトリクスを元にアラートを行う ①通知先のSNSトピックを定義する ②メトリクスに対し
CDKだとIConnectableインタフェースのプロパティであるconnectionsを使うことで通信の許可設定を容易に行えることを最近知りました。 今まではセキュリティグループ(以下SG)を個別に定義し、インバウンドルールを設定ということをやっていましたが、上記の方法にするともっと楽にできそうです。 キャッチアップがてら色々試して整理した結果をまとめます。 目次 目次 今までどうしていたか IConnectableのconnectionsを使用した通信設定について Connectionsで用意されているメソッドについて ケース1:IConnectableリソース間で通信許可を行いたい場合 ケース2:任意の通信先への通信を許可したい場合 ケース3:任意の通信元からの通信を許可したい場合 ケース4:自己参照のインバウンドルールを追加 ケース5:connectionsの管理下にセキュリティグ
背景 AWS CDKでAurora MySQL 2(5.7互換)を使用していた。しかしAurora Serverless v2の検証をしたいため、Aurora MySQL 3(8互換)にアップグレードをする必要があった。 以下の記事に記載の通り、簡単にアップグレードできるものと踏んでいたが、かなりハマったので試したことをまとめておく。 zenn.dev ※おまけでCDK v2.50.0時点でAurora Serverless v2を実装する方法も記載。 前提 今回アップグレード対象のAurora MySQLは独自のDBクラスターパラメータグループ、DBパラメータグループ(カスタムパラメータグループ)を使用しているAuroraクラスターである。 2つのパラメータグループの違いや適用優先度等は以下を参照。 https://dev.classmethod.jp/articles/aurora-p
AWS CDK v2.82.0でAurora Serverless v2が正式にL2 Constructに対応しました。 AWS CDK v2.82.0 新機能✨#cdk_releases ⑥Aurora Serverless v2を利用可能に。設計時の判断を記述するArchitecture Decision Record (ADR) も公開されているため興味がある方はご覧ください https://t.co/hVba6946vj— Kenji Kono (@konokenj) 2023年6月2日 ※AWSの方によるCDKのアップデートに関するツイート。いつもこれでキャッチアップできており非常に助かっています。ありがたい。 これにともないAWS CDKでRDSのAPIに変更が入っています。 そのため単に確認するのみではなく、旧APIからの移行について検証してみました。 最初に試したこと、およ
はじめに AWS WAFのマネージドルールについて、観測範囲における誤検知あるある事象をまとめておく。 AWS WAFの意図せぬブロックあるあるを知りたい。 複数のプロジェクトで経験したのはリクエストボディ8kb越えでブロックされるのと、OIDCのエンドポイントへのリクエストがSQLインジェクションにされるやつ— mazyu36 (@mazyu36) 2023年1月18日 概要とよくとる対処方法を記載している。ただし対処についてはサービスの要件等を踏まえ、どこまでのリスクを許容するかを判断して設定する必要がある。 緩和する際もいきなりAllowにするのではなく、Countモードを活用し想定通りの挙動となるか確認した方が良い。以下参考リンク。 blog.denet.co.jp はじめに リクエストボディ8kb越えによるブロック(SizeRestrictions_BODY) 概要 対処方法 フ
本ブログでは何回かAWS CDKで構築したAurora(RDS)クラスターを運用の観点で検証してきました。 当たり前ですがCDKで作ったとしても、そのあとは運用を行っていく必要があるので、運用継続ができるかは重要かと思います。特にDB(ステートフルなリソース)は扱いが難しいため、さまざまな検証をしています。 AWS CDKにおけるAurora MySQLのリカバリについて - mazyu36の日記 AWS CDKでカスタムパラメータグループを使用しているAuroraのアップグレード方法(+v.2.50.0時点でServerless v2を使用する方法) - mazyu36の日記 AWS CDKで作ったAurora グローバルデータベースは運用できるのか - mazyu36の日記 今回はAmazon RDS Blue/Green Deployments(以降B/G デプロイと記載)が題材です
Amazon AthenaにPartition Projection(パーティション射影)という機能があります。 dev.classmethod.jp ざっくりいうとパーティション管理を自動化して、高速にクエリが実行でき、お財布にも優しいというものです。個人的にはめちゃくちゃ便利だなと思い、特にログの調査に活用しています。 ログ調査対象のサービスの内、大体どのプロジェクトでも使っているものがいくつかあります(ALB、VPCフローログ、CloudTrail....)。 これまではPartition Projectionの設定を行うCREATE文を毎回実行していたのですが、少し面倒なのでAWS CDKで実装し使いまわせるようにしました。 今回の実装の全体像は以下です。 1. 概要 対象のログ 実装方法 2. 実装詳細 プロジェクト構成 実装の流れ 入力のインタフェース Glue データベースを
AWSのログ管理についてはいくつか考えるポイントがあると思います。 どのログを保存するか。 CloudWatch Logs(以下CW Logsと記載)とS3のどちらに保存するか、もしくは両方に保存するか などなど。 システムの特性によるところも多いかと思いますが、自分の中でのログ管理のベースラインが定まりつつあるので、頭の整理がてらまとめます。 自分の中での大まかな方針としては以下です。 S3に保存できるものは基本S3に保存する。 以下の場合は、CW Logsに保存する。必要に応じてS3に転送する。 アラームを出したい場合 さっとCW Logs Insightでログを確認したい場合 CW Logs に出さざるを得ない場合 全体像としては以下になります。 なおあくまで個人的な経験に基づくものなので、実際にはシステムの特性を踏まえて方針の決定が必要かと思います。 またこれは必要、これは不要など
-----(2024/3/25追記) ----- 本記事の内容は古いです。2024年時点では本記事のように「計画外フェイルオーバー」時にクラスターの切り離し作業などが不要です。 詳細は以下をご覧ください。 mazyu36.hatenablog.com ----- 追記ここまで ----- リージョン間フェイルオーバーを行うため、Auroraグローバルデータベースを検討することはあるかと思います。 ※Aurora グローバルデータベース:リージョン間でデータをレプリケートし、リージョンを跨って運用するための仕組み。 https://pages.awscloud.com/rs/112-TZM-766/images/ORL-T4-Session.pdf Primaryのリージョンを切り替える際に当然フェイルオーバー操作が発生します。このフェイルオーバー操作がIaCとはなんとも相性が悪そうです。
初めに Fargate BastionとAthena Federated Queryを使って、サーバレスでAurora MySQLを手軽に運用する仕組みを導入したところ、なかなか便利だったのでまとめておく。 初めに 背景 1. Fargate Bastionを使うまでの準備がめんどくさい 2. 権限の管理が簡易にできない 3. 踏み台の利用に抵抗がある Athena Federated Queryの導入検討 構築した仕組み 1. Fargate Bastionを使うまでの準備がめんどくさい → Fargate Bastionの使用頻度減 2. 権限の管理が簡易にできない → Fargate BastionとAthenaの実行権限で管理 3. 踏み台の利用に抵抗がある → データ参照はAthenaを使用するだけで可能に AWS CDKで Athena Federated Queryを実現する
はじめに 入門監視をはじめ一般的な監視に関するプラクティスは出回っているものの、AWSで具体的に何を監視するか?そのとっかかりについてはあまり出回っていないような気がします。 AWSの監視ってみんな何監視してるんすか…っていうぐらい実例あまり見つからないな。門外不出?— mazyu36 (@mazyu36) 2023年2月14日 どこまで監視するかは基本的にシステムの特性によると思います。一方でAWSのサービスごとにシステムによらずよく監視で使う項目というのもあるかと思います。 今回は過去の経験をもとに、最低限この辺りは監視することが多いかなというものをまとめてみます。全体像としては以下になります。 最低限これは監視しないとダメでしょ、とかこれは不要でしょ、などなどあるかと思います。そういうのがあればぜひコメントいただきたいです。 はじめに 「監視」について 前提 1-1. Webサービス
はじめに 今年度初めてAWS CDKによるチーム開発を行ってみた。その際に採用したソースコードのプロジェクト管理方法や、デプロイのフローについて考えたこと含め整理としてまとめておく。 ※これが最適だとは思っていないので、イマイチな点などあれば意見もらえると嬉しいです。 なお、考えたことが以下の書籍で言語化されている箇所もあったので、必要に応じて引用させていただく(オライリーのInfrastructure as Codeの第2版。2023/1現在で、残念ながら邦訳は第1版のみ。)。 Infrastructure as Code: Dynamic Systems for the Cloud Age (English Edition) 作者:Morris, KiefO'Reilly MediaAmazon はじめに 前提 導入検討時の話(そもそも言語どうする問題) 全体像 1. CDKのプロジェ
このページを最初にブックマークしてみませんか?
『mazyu36.hatenablog.com』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く