はじめに おはようございます、クラスメソッド MAD事業部の加藤です。 この記事はAWS CDK Advent Calendar 2021のカレンダー | Advent Calendar 2021 - Qiitaの7日目の記事です。 本記事はAWS CDKにおけるスタックをどのように分割するかについての現時点での私の見解をまとめたものです。1つのWebアプリケーションを構築するという環境を想定しています。 文章の見やすさの為に記事中では言い切り系ですが、内容は全て私の私見、そして自分の観測範囲での話です。 CloudFormationとCDKのスタック分割は同じで良いか CDKはCloudFormationテンプレートを生成してAWSリソースの作成を行います。CDKからCloudFormationへ強い依存関係があります。しかし、CDKのスタック分割はCloudFormationとは別で考

はじめに 今回はスタックの分割方法を紹介します。 CFn で言うと クロススタックの参照 と呼ばれる機能を CDK で実現します。 [参考]：Stacks | AWS CDK v2 Developer Guide 前回の記事はこちら。 スタック分割のメリット スタックを分割することのメリットは一言でいうと 管理がしやすくなる です。 共通のライフサイクルやリソースでグルーピングできるため、他のスタックに影響を与えることなく目的のリソースを作成・更新することができます。このため複数のメンバーでスタックを作成・変更する場合もコンフリクトが発生しづらくなります。また、単一スタックだとデプロイ時にエラーが発生した場合はすべてのリソースがロールバックされてしまいますが、スタックを分割しておけばロールバックもスタック単位となります。 [参考]：ライフサイクルと所有権によるスタックの整理 | AWS C

AWS CDK TIpsシリーズの記事です。 AWS CDKのスタック、まとめてますか？分けてますか？分けている方はどういう基準で分けていますか？ この議論は人によって割と意見の分かれることも多く、最高の飲み会ネタになるでしょう。今日は私見も交えながら、CDKのスタック分割法についてまとめてみたいと思います。 自己紹介 私見を語る上で自己紹介は必要だと思うので、私自身のCDK経験を簡潔に: CDKは2020年の頭に出会い、以下のようにかれこれ3年ほど使っています。 前職ではそれなり規模のmBaaSをCDKを使ってAWSに移行･運用していました 現職では大小様々な規模のプロトタイプ開発にCDKを使っています。数えるとこれまで15個くらいシステムのプロトタイプを作ったようです。 現職のサイドプロジェクトとして、グローバル規模の社内システムの開発運用もCDKでやってました (お手伝い程度)。AW

デプロイに伴うダウンタイムが好ましくないのは、クラウドの登場以前も同じでした。 多くの企業は、アプリケーションをホストする従来のデータセンターでローカル ユーザーからのアクセスに制限を設け、ユーザーによるアプリケーションの利用頻度が低い深夜などの時間にデプロイ スケジュールを設定するといった工夫をしていました。 クラウドをベースにした 24 時間年中無休の環境が広く普及すると、あらゆるタイムゾーンから四六時中アクセスが来るようになり、デプロイを設定しやすい時間帯はなくなりました。 現在はどの企業でも、アプリケーションを利用するかもしれないすべてのユーザーに対して、アクセスできない時間帯を作らないことが課題になっています。 以前は、変更や更新のデプロイ時にアプリケーションをオフライン状態にする手法が一般的で、これによってダウンタイムが発生していました。 現在では、アプリケーションのビルドから

最高の開発者体験を目指して AWS CDKでCI/CDパイプラインを 改善し続けている話 株式会社ニューズピックス 安藤 裕紀 2023.3.20@CI/CD Conference 2023 by CloudNative Days

AWS CDK Conference Japan 2023 3年間運用したCDKの失敗から学ぶ CDK開発のプラクティス 2023/5/20 Yuki Ando あんどぅ JAWS-UG CDK支部の活動を応援したいおじさん 経済ニュースの事業会社のSREチームのリーダー インフラ畑出身で、コーディングはそこまで得意じゃないです 好きなAWSのサービス：ECS、Cost Explorer、CDK @integrated1453 JAWS-UG SRE支部 2 CDKと私 AWS歴が長いのでCDK自体はGA前のβの頃から触っており、もうすぐ5年近くになります。 初期構築でコードを設計・実装した時間よりも、インフラ担当の日々の運用のお仕事として メンテナンスでコードを修正・適用する時間が多く、コーディングに自信ニキではないです😇 2018年夏頃〜 2019年7月頃(GA後)〜 CDK β (

不正アクセスによるIDとパスワードの漏洩を受けて、MD5によるハッシュ化について話題になっていました。システムを作る上で、パスワードの管理や認証はどう設計すべきかを考えるために、少し整理をしてみます。もし事実誤認があれば、どしどしご指摘ください。 == 2023/8/21追記 == この記事は、ハッシュの保存の仕方一つとっても、沢山の対策方法が必要であるということをお伝えするために記載しています。そして、これから紹介する手法を取れば安全とお勧めしている訳ではないので、その点をご留意いただければと思います。攻撃手法に応じての対応策の変遷を知っていただくことで、セキュリティ対策は一度行えば安全というものではないことを知って頂くキッカケになれば幸いです。 == 追記終わり == パスワードのハッシュ化 まず最初にパスワードの保存方法です。何も加工しないで平文で保存するのは駄目というのは、だいぶ認

はじめまして。そーだい（@soudai1025）です。私は普段は技術コンサルティングや受託開発を請け負う合同会社HaveFunTechの代表として、また、予防治療の自社サービスを展開する株式会社リンケージのCTOという二足の草鞋を履き、日々、さまざまなWebサービスの開発に携わっています。 これまでの開発経験のなかで、データベース設計に関わるさまざまな問題に遭遇してきましたが、本稿ではとくに、アジャイル開発時に発生しやすい問題とその対処についてお伝えしたいと思います。開発の現場で目にしやすい実装におけるアンチパターンを示しつつ、アジャイルという指針を維持しながら、対処となるデータベース設計についてご紹介します。 会員登録のアンチパターンと処方箋 イージーな実装とシンプルな実装 Userと言う名の罠 拡張と破綻 データベースは変化に弱い 仕様変更とテーブル変更 Addで変化に追従する 正規化