PR TIMESのCDNをCloudFrontからFastlyに移行しました こんにちは、インフラチームテックリードの櫻井です。 今回はプレスリリース配信サービスの prtimes.jp で使用しているCDNをCloudFrontからFastlyに移行したことについ... なお該当のAPI以外へのリクエストは正常に処理できていたため、PR TIMESへのリクエストが一律でブロックされている状況ではなかったと考えられます。 根本原因の仮説と検証 ここまでの調査でわかったことは以下です。 該当のお客様から行われたメディアリスト保存APIへのAJAXリクエストは、501エラーとしてNew Relicに記録されている。 該当のお客様から行われたメディアリスト保存APIへのAJAXリクエストは、PR TIMESシステムに到達していない。 該当のお客様から行われた他のAPIへのリクエストは、正常にレス
はじめに 先日、Xでこんな投稿が話題になっていました。 実際のサイトを見ていないため詳細は不明ですが、事象としてはフロントエンドのJavaScriptだけでバリデーションを実装し、サーバーサイドに同等以上のバリデーションがなかったケースです。 DevToolsで回避できるということは、悪意あるユーザーが不正なデータを送信できてしまいます。 サーバーサイドではすべてのバリデーションを実装するべきです。セキュリティの観点でも、ドメインの正当性を保つ意味でも、サーバーは最後の砦となります。 一方で、フロントエンドのバリデーションについては、どこまで実装すべきか判断が難しいところです。本記事では、この点について考えを整理してみます。 バリデーションの責務を整理する 前提を決めておきます。 サーバーサイドバリデーションは絶対 サーバーサイドのバリデーションは必須です。これは絶対に省略できません。 理
AWS の新卒社員が考えた寿司配送システムのアーキテクチャを、ベテラン社員にレビューしてもらってみた
How to be a Developer AWS の新卒社員が考えた寿司配送システムのアーキテクチャを、ベテラン社員にレビューしてもらってみた 2025-11-04 | Author : 冨山 英佑, 菅原 太樹, 濵 真一 AWS Summit 2025 で、小さな寿司屋が開店していたことをご存知ですか ? 残念ながら回転はしていないのですが、開店はしていました。 時は遡り、2025 年 6 月。幕張で行われた AWS Summit Japan 2025 では、2024 年に入社した新卒ソリューションアーキテクトたちによる寿司配送システムが展示されていました。「Cloud Sushi」と名付けたこのプロジェクトは、AWS Step Functions と AWS IoT Core をベースに設計された、寿司配送モノレールのデモンストレーションです。 来場者の方々に実際に体験していただき
はじめに スキーマ分離と行分離 目的と結論 目的 結論のサマリ 試験内容 試験環境とツール 負荷の設計 本番環境でのクエリ傾向の分析 QPSの測定 進め方 試験結果 スキーマ分離のボトルネック スキーマ数を固定して負荷をあげてみる 結果まとめ なんとか延命したい はじめに 弊社が採用しているDB設計は、テナントごとに独立したスキーマを持つ「スキーマ分離」 のデータ構造に基づいています。このアーキテクチャは、高いデータ分離性とセキュリティを確保できる一方で、「スキーマ数の増加に伴ってパフォーマンスが劣化する」という性質が指摘されます。 サービスのスケールにおいてこの「性能劣化」が、いつ、どのように顕在化するのかは、設計上の大きな課題でした。この漠然としたリスクを定量的に評価し、将来的な「行分離」アーキテクチャへの移行の是非を判断することを目的に、負荷試験を実施しました。 本記事では、この試験
こだわりがチラッと見える仕事が好きなんですよね。 そんなの気にしない人や気づかない人も多いのかもしれない、でも気づく人は気づいてるよってやつを見つけた瞬間が楽しいのです。 私はソフトウェアエンジニアとして、「こういう機能があったら便利だな」という小さなこだわりを大切にしてきました。その一つが、検索条件をURLに残すという実装です。 例えばフリーワード検索ならURLの末尾に「?q=hoge」とか入るようにするし、さらに名前で順番を指定しているなら「?q=hoge&sort=name.desc」にするとかですね。 これ何が嬉しいかって条件ごとにブックマークしたりドキュメントに貼った時に便利ですし、Chromeのサイト内検索のショートカットやRaycastなどのランチャーアプリから可変部分だけを入力してサクッと条件付き検索できるんですよね。 こういうのって機能比較の○×書いているような表にはもち
はじめに 技術選定やアーキテクチャ設計は簡単な仕事ではありません。 資格の勉強を通して各クラウドサービスの機能がわかるようになったから・プログラミング言語を勉強してアプリコードが書けるようになったからといって、では次のステップとしてアーキテクチャ設計ができるか？と言われると必ずしもそうではないことの方が多いのではないでしょうか。 このサービスを用いることでシステムの機能要件を問題なく満たせるという理由で技術選定した結果、全然パフォーマンスが出ない・コストがかかり過ぎるといった問題が発覚して、運用やビジネス遂行に支障をきたしてしまうこともあります。 このような失敗を未然に防ぎ、システムがその役割を十分に果たすために必要となるアーキテクチャを先んじて確実に見通し設計するには、私たちは一体どのようなことを学び、気をつければいいのでしょうか。 この記事では、アーキ設計・技術選定において大きな失敗を
1. 猜疑心か相互信頼か、防御的か契約に基づくか 防御的プログラミングと契約プログラミングについて、後述する勉強会で疑問を持ち、勉強会内で説明されていること深堀りしてみました。 asken.connpass.com すべてが勉強になる話だったのですが、こちらの記事でフォーカスするのは「クラス設計スタイル」におけるふたつの選択肢 トランザクションスクリプト方式 ドメインモデル方式 に登場する「防御的プログラミングと契約プログラミング」になります。 トランザクションスクリプト方式が「防御的プログラミング」 ドメインモデル方式が「契約プログラミング」 増田さんのお話ではクラス設計において変更容易性を実現するには「ドメインモデル方式」選択すべきというお話でした。 本記事では、実装フェーズにおいて、各クラスがどのレイヤー以降なのか？によって、防御的・契約どちらのプログラミングを行うべきか異なる。とい
ユーザなどのリソースエンティティのパージするわけではないデータ削除(a.k.a. 論理削除)をどう設計するか、は単純でありながら、イミュータブルデータモデルの基本形を学ぶ良い題材なので、順を追って説明する。 リソースの検討 まずユーザがアクティブなユーザと削除されたユーザで扱いが異なるかどうかを考える。この段階で物理設計としてどうするかを考えると検討ポイントが十分考慮されないことにつながるので注意しよう 。(イミュータブルデータモデル#5e3a5f1da8e5b200009c0499) 扱いが異ならない場合を考えてみよう。 code: (mermaid) classDiagram direction LR class ユーザ { <<Resource>> ユーザID : SERIAL PK 名前 : VARCHAR メールアドレス : VARCHAR ユーザ区分 : ENUMアクティブ/削
バッチ設計ガイドライン チーム開発する上で必要となるバッチ設計ガイドラインです。 次のリンクから単一ファイル版を取得できます。 Markdown
影牢🦐 @aki_kagero ライブ前に駅ロッカーに荷物を預けたら大変なことになった話 ・エラーが出ても預けられてしまった ・駅員が荷物を管理会社に渡した(マニュアルなのかもしれないがその駅で保管できないのか) ・管理会社受付が8:00-21:00で、21時過ぎていたので詰んだ ネット予約できるロッカーのトラブル怖い pic.x.com/3o3nMjPIPx 2025-06-10 11:55:28
JJUG CCC 2025 Spring で話したものです。 昨今の生成AIによって、偶有的な難しさは激減した。し、これからも減り続けることだろう。 だが、本質的な難しさ(複雑さ)が変わるわけではない。 「本質的な複雑さ」とは何か？ 本質的な複雑さにはどうアプローチすれば良い? 本質的な複雑さはどう設計しても変わらない。 すなわち本質的複雑さは保存法則がある。 だが、本質的複雑さはその度合いに応じてComplexとComplicatedの複雑さがある。Complexな状態では、本質的複雑さがどれだけ含まれているかが把握できないことがある。動かしてみないと分からない、動かしてみても分からないことも… したがって、データモデリングを通じて「時間と労力さえかければ理解可能」な状態にしておくことが重要。 Complicatedな状態に持っていくために、イミュータブルデータモデルでモデリングすると良
本ガイドラインは、世の中のシステム開発プロジェクトのために無償で提供する。 ただし、掲載内容および利用に際して発生した問題、それに伴う損害については、フューチャー株式会社（以下、フューチャー）は一切の責務を負わないものとする。 また、掲載している情報は予告なく変更する場合があるため、あらかじめご了承いただきたい。 免責事項: 有志で作成したドキュメントである フューチャーには多様なプロジェクトが存在し、それぞれの状況に合わせて工夫された開発プロセスや高度な開発支援環境が存在する。本ガイドラインはフューチャーの全ての部署／プロジェクトで適用されているわけではなく、有志が観点を持ち寄って新たに整理したものである相容れない部分があればその領域を書き換えて利用することを想定している プロジェクト固有の背景や要件への配慮は、ガイドライン利用者が最終的に判断すること本ガイドラインに必ず従うことは求めて
「アーキテクチャ」に対する一般的なイメージ インフラ設計図のような青写真──機能やデータがどこに配置され、どう結び付くかを俯瞰で示す全体像。 システムの骨格とルール──技術スタックやモジュール分割、データフローなど「こう作るべき」を規定する枠組み。 将来への建築基準──性能・安全性・保守性を支え、変更や拡張の自由度を左右する長期的な基盤。 「アーキテクチャ」の本質的な意味 建築から哲学、テクノロジーまで幅広い分野で使われ、人間の行動様式や社会関係を規定する重要な要素となっている。 建築物が人の動きを決めるように、社会制度やテクノロジーのアーキテクチャも私たちの行動や権力関係に影響を与えている。 ローレンス・レッシグのアーキテクチャ アーキテクチャは、人々の行動を規制する4つの力(法、社会規範、市場、アーキテクチャ)の1つとして定義される 「ある選択肢を選びやすく/選びにくくする」 という性
こんにちは。Strategic AI Group の佐藤です。 フューチャーでは さまざまなガイドラインを公開しており 、本ブログでも 「ガイドライン」タグ に過去の紹介記事がいくつか載っています。Web API に関するガイドラインも昨年11月から検討を開始し、今年の 1/17 に 公開されました！ 本記事はそのご紹介です。 4ヶ月も寝かせていて本当に申し訳ありません 本ガイドラインの経緯フューチャーでは様々な規模、様々な環境で動くシステムを構築しています。システム開発におけるバックエンド設計かくあるべしという共通知識は大規模システムに偏っていて、昨今急速に数を増やしている Web ベースのシステムに限った話というものはあまり言語化されていませんでした。 そこで今回、設計の属人性を軽減させ、知識の横展開を容易にするべくガイドラインを作成・公開しました。当初はHTTPメソッドやステータスコ
SaaS設計レビュー 観点チェックリスト【2025年版】 SaaS設計における「レビュー観点が足りない」「属人化している」を防ぐための 設計レビュー観点チェックリストを整理しました。 実務でよく聞かれる質問・盲点も交えながら、設計品質を上げる観点を体系的にまとめる試みです。 この記事を英語圏向けに再編したものを MITライセンスのOSSとして公開しています。 👉 SaaS Architecture Review Navigator また、この記事群をAIに活用したい方は、こちらの記事を必ず確認してください。 👉 このドキュメントは要約不可です：構造を壊さずAIに読ませるための手引き：要約・誤読・再生成の抑止 概要 このドキュメントは、SaaSの現場で必要と思われる設計観点を体系化したものです イベント駆動・非同期設計・マルチテナント対応・分散トランザクション・災害対策など、現代的な分散
クラス設計の考え方とやり方 クラス設計の目的 - ソフトウェアの複雑さを扱いやすくする - ソフトウェアの変更を楽で安全にする クラス設計の三つの視点 - 関心の分離 - 依存関係 - モジュール性 クラス設計の５つの技法 - 計算判断と入出力の分離 - 中核と周辺の分離…
こんにちは。クラウド型電子カルテであるエムスリーデジカルのソフトウェアエンジニア兼 Team SRE をしている井上 渉（@wtr_in）です。キャベツ相場が落ち着いてきて一安心しています。 今回は、デジカルを構成するサービスの DB（基本的に読み取りのみ）を Aurora MySQL から Fargate 上の SQLite に移行し、性能も向上しつつ当該サービス全体のインフラコストを約 1/8 まで大幅に削減できた話をご紹介します。 移行前・移行後の構成とその効果 移行前 (Aurora MySQL) 移行後 (SQLite) 移行で得られた効果 移行を検討した背景 なぜ SQLite を選んだか SQLite のデータをどこに置くか インメモリ SQLite へのデータロード まとめ We are hiring! 移行前・移行後の構成とその効果 今回 SQLite を採用したサービス
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
