サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
ドラクエ3
mazyu36.hatenablog.com
前回以下の監視アラートに関する記事を書きました。(予想以上に反響がありました。ありがとうございます) mazyu36.hatenablog.com 監視アラートの基準はシステム特性によるものの、同じメトリクスを使用する場合は閾値や集計期間がシステムによって違うぐらいで仕組みとしては同じため、なるべく使い回しができるようコード化しておきたいところです。 今回は監視アラートをAWS CDKで実装する方法について簡単にご紹介したいと思います。 ※CDKユーザーの中にはご存じの方も多いかと思いますが、特にメトリクス監視はAWS公式のBLEAにも実装がされており非常に参考になります。本記事においても数多く引用させていただいております。 github.com 目次 目次 実装したいもの (1).各サービスから収集したメトリクスを元にアラートを行う ①通知先のSNSトピックを定義する ②メトリクスに対し
はじめに 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 に出さざるを得ない場合 全体像としては以下になります。 なおあくまで個人的な経験に基づくものなので、実際にはシステムの特性を踏まえて方針の決定が必要かと思います。 またこれは必要、これは不要など
はじめに 入門監視をはじめ一般的な監視に関するプラクティスは出回っているものの、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ページを開く