はじめに こんにちは！DPE（Developer Productivity Engineering）チームの高畑です。 ちょっと前に iPhone 15 Pro に変えてようやく USB-C ケーブルに統一できる！と思っていたら、手元にある Magic Trackpad が Lightning ケーブルでしょんぼりしました。 さて今回は、ビザスクのインフラ周りで利用している Terraform をエンジニア全員が安心・安全に利用できる仕組みづくりを行なっている話をしていきます！ これまで ビザスクではインフラの構築・運用に Terraform を利用しており、依頼ベースで DPE のメンバーが Terraform の修正を行なってレビュー＆リリースをしていました。 開発メンバーから Terraform の PR をあげてもらうこともありますが、plan / apply の権限を持っていない

はじめに こんにちは。ブランドソリューション開発部プロダクト開発チームの木目沢とECプラットフォーム部カート決済チームの半澤です。 弊社では、ZOZOTOWNリプレイスプロジェクトや新サービスで、Amazon DynamoDBを活用することが増えてきました。そこで、AWS様から弊社向けに集中トレーニングという形でDynamoDB Immersion Daysというイベントを開催していただきました。 今回は、2021年7月6日、13日、14日の3日間に渡って開催された当イベントの様子をお伝えします。 7月6日のDay1及び、14日のDay3の様子をDay1のサブスピーカーとして参加した木目沢がお届けします。13日のDay2を同じくDay2にてサブスピーカーとして参加しました半澤がお届けします。 目次 はじめに 目次 Day1（2021年7月6日） Amazon DynamoDB Archit

最近ネットを見ていると要件定義入門的な記事とか、あと要件定義は不要みたいな記事が目についたので思ったことを書いてみる記事その２。ITシステム開発における要件定義に関するあれこれ。本記事には前編があります。 目次 要件定義以前 要件定義の進め方 IPAユーザのための要件定義ガイドをベースにする 決め過ぎない 機能を定義するのではなく、機能要件を定義する 関係者をすべて洗い出す 利用者マニュアルの目次が作れるようになっているか ビジネス要件定義 前提事項、制約事項とリスクを定義する 優先順位の決定を忘れずに システム化要件定義 不安定な要件を構造で支える おまけ：本記事の元ネタ 要件定義以前 要件定義というプロセスが本当に必要なのか、ということなどは以下の記事に書いたので省略。 実践要件定義入門以前 - 勘と経験と読経 要件定義の進め方 IPAユーザのための要件定義ガイドをベースにする 前編に

Front-End Web & Mobile Connect a React app to GraphQL and DynamoDB with AWS CDK and Amplify Today, we’re excited to announce the official AWS Cloud Development Kit (CDK) construct for Amplify’s GraphQL APIs capabilities. With Amplify’s GraphQL API CDK construct, you can create a real-time GraphQL API backed by data sources such as Amazon DynamoDB tables or AWS Lambda functions using a single Graph

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

ドメインイベントとはドメイン駆動設計において、ドメインエキスパートが気に掛けるなんらかのイベントの事をモデルで表現したものになります。また、複数の集約の状態を同期する事にも用います。ドメインイベントがドメイン内の集約を非同期的に更新する場合、イベントの配送を行うなんらかの実装がなければなりません。今回はSpringFrameworkを使用してイベント配送の仕組みの実装をしてみました。 ドメインイベントとは？ドメインの中には、なんらかのイベントに関心があるものがあります。例えば、ドメインエキスパートの言葉の中に「〜の場合は通知が欲しい」とあった場合、対象をドメインイベントとしてモデリング、実装する方法が考えられます。一方、ドメインエキスパートからドメインイベントの必要性を感じさせるような言葉がなかったとしても開発者が必要に応じてドメインイベントを定義する場合もあります。 ドメインイベントは下

ドメインイベントとは ドメインイベントは DDD に登場するドメインオブジェクトのひとつで，あるドメインで発生する出来事を表現したものです．ドメインの中では，「〜が行われた時」や「もし〜になったら」といったような特定の出来事の発生を契機に別の何かを行うことがあります．この出来事の発生をドメインイベントとして表現し，ドメインイベントが生成されたらそれをパブリッシャが出版 (publish) し，サブスクライバがドメインイベントを購読 (subscribe) して何らかの処理を行います． ドメインイベントの使い道として典型的なのは，結果整合性を用いてある集約が変更されたときに別の集約を非同期で変更するといったものです．たとえば，メッセージが投稿された時に，そのメッセージの通知を非同期で作成するといったものが考えられます．同一トランザクションで複数の集約を同期的に変更することは非推奨とされている

はじめに DDD の集約の実装について考えたことをまとめます。 題材 料理のレシピ作成を題材としてまとめていきたいと思います。 概要 概要は以下の通りです。 レシピには材料と作り方がある。 材料には食材や調味料などの名前と分量が必要である。 材料はメインとなる材料や合わせダレなどのカテゴリごとにグルーピングできるとよい。 作り方は具体的な手順を示すものである。 ドメインモデル 上記をドメインモデルで表現するとこのようなイメージです。 各種値の範囲はドメインとして決まっているわけではないですが、システム化する上で決めなければならないことだと思いますので、ドメインエキスパートとすり合わせながら運用に支障をきたさない範囲で決定すると良いのかなと思います。 今回は決定した値の範囲をドメインモデルに補足する形で記載しています。 ユースケース システムに対するユースケースは以下の通りとし、末端のユース

プロローグ 膨れ上がる要件、複雑化していくAPI システムを開発していると、どんどん要件が増え、一つのAPIの呼び出しで様々な処理を行う必要が出てくることがあります。 例えば予定を登録するAPIを実行したら、DBにデータを保存し、Googleカレンダーにもイベントを作成し、予定の開始時刻直前に通知を出すためのタスクを登録したり、同様に終了時刻直前に通知を出すためのタスクを登録したり・・・。 この様に１つのAPIに対する要求が増えてくると、プログラムが複雑になり、それぞれの処理のエラーハンドリングなどが増え制御が難しくなっていきます。 また、Googleカレンダーに連携するなど、外部サービスに依存する場合はそことの通信コストがかかり、レスポンスを返すのが遅くなったり、外部サービスがダウンしている場合はAPIも失敗することになり、システムの可用性が下がります。 非同期処理の必要性 処理をシンプ

こんにちは。スタディサプリの小中高プロダクト基盤開発グループでProduct Platform Engineer兼テックリードをやっている@tooooooooomyです。 今回は、WebアプリケーションにGoの並行処理機構を導入してSLOを改善し、WebAPIを100倍速くした話をしたいと思います。 前提条件 システムを0から作らない場合、アーキテクチャの改善の際には前提条件が付きものです。そこでまずは今回のシステムの前提条件をお話します。 対象となるシステムと、アーキテクチャ 今回対象とするシステムは、ここでは security-tracker と呼び、Webアプリケーション本体はGoで書かれています。 スタディサプリの各アプリケーションにおけるユーザーのログ1を、Amazon Kinesis Firehoseを通して、リクルート全体のセキュリティチームが管理するS3バケット(スタディサ

全方位防衛戦略（読み）ぜんほういぼうえいせんりゃく（英語表記）défense tous azimuts; omnidirectional defence フランスの核戦略。 1967年 C.アイユレ参謀総長が提唱し，ドゴール大統領が採用。フランスの仮想敵国は第1次世界大戦後はイギリス，ドイツ，第2次世界大戦後はソ連と変化したが，世界情勢の流動化によってソ連1国に固定すべきでなく，全世界を対象とすべきであり，したがって全世界を射程内に収める ICBMとミサイル潜水艦を保有しなければならない。さらに同盟に加わることは，他国の戦争に巻込まれる危険が高いので，みずからの防衛体制をもって戦争抑止をはかるというもの。ソ連の脅威が減少し，アメリカのいわゆる「核の傘」への不信の増大という判断に助けられ，フランスの北大西洋条約機構 NATO脱退を裏づける防衛哲学となった。この背景には，フランスの核武装からフ

ドメインイベントは過去に起きたドメイン上の出来事を意味します。「過去に起きた」なので後から変更できません。つまり不変(イミュータブル)なモデルです。 昨今、このドメインイベントはCQRS/Event Sourcingやマイクロサービスなどの書籍で取り上げられ、実際に実装上でドメインイベントが利用される事例も増えています。このように有益性は認識されつつありますが「うちはEvent Sourcingじゃないのでイベントは関係ありません」と視野が狭くなっている方もいます。 たとえ実装で使えなくても、ドメイン分析に基盤的な視点を与えてくれるのがドメインイベントです。 ともあれ、この資料は「そもそもドメインイベントはソフトウェア設計にどのような影響を与えるのか」を解説します。

DynamoDB では、テーブル、項目、および属性が、操作するコアコンポーネントです。テーブルは項目の集合であり、各項目は属性の集合です。DynamoDB は、プライマリキーを使用してテーブルの各項目を一意に識別し、セカンダリインデックスを使用してクエリの柔軟性を高めます。DynamoDB Streams を使用して、DynamoDB テーブルのデータ変更イベントをキャプチャできます。 DynamoDB には制限があります。詳細については、「Amazon DynamoDB のサービス、アカウント、およびテーブルのクォータ」を参照してください。 次の動画では、テーブル、項目、および属性の概要を説明します。 テーブル、項目、属性 テーブル、項目、属性 基本的な DynamoDB コンポーネントは以下のとおりです。 テーブル – 他のデータベースシステムと同様、DynamoDB はデータをテーブ

前提 Amazon Auroraを利用する際には、 基本的には、クラスター構成でMulti-AZにするのが一般的ですよね。 リザードDBインスタンスを購入する際に、 ちょっと混乱したので、ナレッジとして記載します。 今回はAurora MySQLを利用し、 利用できる最小サイズである「db.t4g.medium」を選択します。 購入導線 AmazonRDS > リザードインスタンス >リザードDBインスタンスを購入 製品説明：aurora-mysql DBインスタンスクラス：db.t4g.medium デプロイオプション：シングルAZ DB インスタンス オファリングタイプ：All Upfront DBインスタンス数：★後述★ 疑問 Multi-AZ構成なのに、選択できるデプロイオプションが、 「シングルAZ DB インスタンス」のみとなっている。 選んでいるDBインスタンスの問題かと思い

CloudFrontのCache PolicyとOrigin Request Policyを使う機会がありました。 基本的な知識とTerraformを使って設定する方法をまとめておきます。 【事前知識】 キャッシュキーとはなにかCache PolicyとOrigin Request Policyを理解するためには、キャッシュキーという概念について理解しておく必要があります。 次のとおり、CloudFrontに対して送信される3つのHTTPリクエストがあるとします。 A：curl https://hoge.co.jp/fugaB：curl https://hoge.co.jp/fuga?s=piyoC：curl -H 'X-Header: XXXX' https://hoge.co.jp/fugaこれらABCのリクエストに対して同じコンテンツを返すのであればCloudFrontからキャッシュ

はじめに CloudFront の Management Console で Behavior を設定していると、こんな見慣れない機能が表示されるようになっていた。 これは何ぞや、と思って調べてみたら 2020/07 のアップデート内容のようだ。 Amazon CloudFront キャッシュポリシーとオリジンリクエストポリシーを発表 かなり新しい機能で、まだ資料が少なかったので自分の理解のために従来と比較して何がうれしいのかをまとめてみた。 TL; DR この機能の実装前はオリジンへのForwardとキャッシュキーの項目が自動的に一致していた Policyの実装によって、キャッシュキーとオリジンへの項目転送を分離してより柔軟で直感的なキャッシュルールを定義できるようになった 1度書いた設定を複数の Behavior で再利用できるようになった 1. CDN / CloudFront の仕

Amazon Web Services ブログ Amazon CloudFront キャッシュポリシーとオリジンリクエストポリシーを発表 Amazon CloudFront の新しいキャッシュポリシーとオリジンリクエストポリシーにより、CloudFront がリクエストデータを使用して、キャッシュキーとキャッシュミス時にオリジンに転送されるリクエストの両方に影響を与える方法をより詳細に制御できます。これにより CloudFront が実行するキャッシュの制御と効率を向上させながら、さらに柔軟性が高まります。これらの設定はすでに部分的には存在していましたが、キャッシュキーの設定はオリジン転送の設定から独立することになります。以前は転送されたデータのほとんどはキャッシュキーを自動的に変更していました。このポリシーにより、ほとんどのリクエスト要素をキャッシュキーに影響を与えることなくオリジンに転