Webサーバーアーキテクチャ進化論2023
はじめに 最近プログラマーとしてのキャリアに一区切りつけようと思っており、これまでのプログラミングの勉強の集大成となるブログを書きたくなったので書く。初めてプログラミングをして、フロントエンド開発をして、サーバーから値が返ってきたときは「どういう仕組みで値が返ってきたんだ？」と疑問に思っていた。ずっと理解したくて理解できていなかった。だからずっと勉強していた。そして最近になってようやく自分の言葉で説明できるようになった気がしたのでブログを書きたい。 2015 年版が自分の原点であり、この記事を書くモチベーションになった このような記事は実は過去に存在している。 FYI: https://blog.yuuk.io/entry/2015-webserver-architecture その記事はサーバーがどういう仕組みで動いていて、どのように進化し、2015 年に至るかを解説してくれた記事だ。自
Sansan Data Hub・Bill Oneアーキテクト対談：事業を支えるシステムの設計方針を公開【前編】 - Sansan Tech Blog
社内に蓄積された顧客データを整理・統合し、マーケティングに最適なデータに進化させる顧客データ統合サービス「Sansan Data Hub」。そして、あらゆる請求書をオンラインで受け取り、請求書受領から月次決算を加速するインボイス管理サービス「Bill One」。いずれも急成長を遂げており、Sansan株式会社の事業の柱になっているサービスです。 これらのサービスは、データの処理効率やシステムの信頼性などを向上させるために、さまざまなアーキテクチャの工夫が行われています。今回は「Sansan Data Hub」と「Bill One」それぞれの開発の中核を担う千田智己と加藤耕太にインタビューし、前後編の2回に分けて記事化。前編では、両サービスのアーキテクチャ設計の工夫や思想について語ってもらいました。 【Sansan Data Hub】アーキテクチャ解説 ――「Sansan Data Hub」
『ソフトウェアアーキテクチャ・ハードパーツ』 - Don't Repeat Yourself
『ソフトウェアアーキテクチャ・ハードパーツ』を訳者の方からご恵贈いただきました。ありがとうございます。献本については基本的にすべて書評を書こうと思っているため、今回も記事にします。発売は10/27のようです。 ソフトウェアアーキテクチャ・ハードパーツ ―分散アーキテクチャのためのトレードオフ分析 作者:Neal Ford,Mark Richards,Pramod Sadalage,Zhamak DehghaniオライリージャパンAmazon おことわり まず指示語についてです。記事中で「本書」「この本」と書く場合は『ソフトウェアアーキテクチャ・ハードパーツ』を指します。また、「著者」は本書を執筆した人を指すものとします。「筆者」といった場合、それは私のことです。 いわゆるスキミングをした状態で一旦書評をするため、本書の細かい議論の見落としや用語の誤認識が含まれる可能性があります。この書評は
ニアリアルタイムで同期される検索基盤 ~パイプライン構築編~ - コネヒト開発者ブログ
皆さん，こんにちは！MLエンジニアの柏木（@asteriam）です． 今回は前回のエントリーに続いてその後編，パイプライン構築の話になります． tech.connehito.com はじめに 再掲になりますが，我々は以下の構成で今回の検索基盤を構築しています． 検索エンジン：Amazon OpenSearch Service データベース：Amazon Aurora データ同期（ETL）：AWS Glue ワークフロー・パイプライン：AWS Step Functions・Lambda・EventBridge 後編は，検索エンジンに定期的に安定してデータを同期するために構築しているワークフロー・パイプラインに関する内容になります（下図の全量データ同期パイプラインの部分）． 検索基盤全体のアーキテクチャー概略図 もう少し具体的には，OpenSearchのindexの管理方法について説明した後に
6 年にわたる Android アプリの開発環境改善への取り組み - ドワンゴ教育サービス開発者ブログ
N予備校 Android アプリ は 2016 年 4 月にリリースされてから執筆時点（2022 年 8 月）まで、6 年以上に渡って開発・運用されてきました。この 6 年間で Android まわりでは新しい技術が続々と登場し、古い技術が次々と非推奨になっていきました。 この記事では、技術の変化が激しかった 6 年間で、Android チームが開発環境の改善に対してどのように取り組んだのかをまとめます。同じく技術の変化と闘っているみなさんの参考になればと思います。 アーキテクチャを整備する（2017 年 2 月 ~ 2021 年 4 月） Kotlin を導入する（2017 年 4 月 ~ 2020 年 9 月） Jetpack Navigation を導入する（2020 年 1 月 ~ 2021 年 4 月） Single Activity にする（2021 年 7 月 ~ 2021
モジュラモノリスに移行する理由 ─ マイクロサービスの自律性とモノリスの一貫性を両立させるアソビューの取り組み｜ハイクラス転職・求人情報サイト AMBI（アンビ）
モジュラモノリスに移行する理由 ─ マイクロサービスの自律性とモノリスの一貫性を両立させるアソビューの取り組み 大規模なソフトウェア開発においてモノリシックかマイクロサービスかというアーキテクチャの議論がありますが、近年は第3の選択肢としてモジュラモノリスが話題になっています。いったんマイクロサービス化に舵を切りながら現在はモジュラモノリスに取り組むアソビューの考え方や進め方について、VPoEの兼平大資（disc99）さんによる寄稿です。 アソビューでは、現在の事業状況にマッチしていることや過去の経緯から、モジュラモノリスを中心としたアーキテクチャを採用しています。 今回は、なぜその選択をし、どのように実現しているかを紹介します。 記事の前半では、アソビューが提供する事業や、アーキテクチャに対する考え方、開発組織の歩みなどを説明します。 中盤以降は、アソビューにおけるモジュラモノリスへの取
高すぎる認知負荷が生むサービスの袋小路とエンジニアリングマネージャーの役割 - yigarashiのブログ
最近流行りの「チームトポロジー」では、フローが改善するようにチームの認知負荷をコントロールすることが述べられています。そのためには組織とアーキテクチャをうまく変化させていく必要があり、いくつか主要な考え方やパターンが紹介されています。詳しく知りたい方は以下の資料を読むと良いです。 【資料公開】30分で分かった気になるチームトポロジー | Ryuzee.com この資料は2022年3月16日の「チームトポロジーを成功させる実践方法の探求」というイベントの発表資料です。このイベントでは、上記の解説に加えて、イベント共催企業で実際にチームトポロジーを適用した様子も紹介されました。それが以下です。 チームトポロジーを成功させる実践方法の探求 - Team Topologies Study、登壇資料 課題の言語化が上手く、しかも実際に素早く変化しており、「とても敵わないな」というのが率直な感想でした
マルチクラウドを考えてみた | フューチャー技術ブログ
秋のブログ週間2021の5日目の記事です。 はじめにこんにちは。TIG DX チームのゆるふわエンジニアの前原です。 私は、企業へのクラウドのアーキテクチャ方針を考えたり、デザイン、構築などの仕事を主にしています。その際によくマルチクラウドの導入をしたい！ という要望を最近受けることが多くなった気がします。そこで本記事では、マルチクラウドを導入するときに何を考えなきゃいけないのかを軽くまとめてみましたので少しでも誰かのお役に立てれば幸いです。 マルチxxについてサービスを稼働させる環境を構築する際に、IPA が提供している非機能要求グレードを参考にするかと思います。 その中にある可用性をどこまで高めるかといった点でマルチxx構成にするかどうかを判断します。その際にキーワードとなるのが、マルチAZ1、マルチリージョン、マルチクラウド構成です。AZ は、AWS が表現しており、GCP ではゾー
クリーンアーキわからんかった人のためのクリーンじゃないけどクリーンみたいなオニオンに見せかけたSOLIDの話
依存関係逆転則含む諸原則に苦しめられた方々，いかがお過ごしでしょうか． 今回はアプリ設計の話です．と言っても，前回「クリーンアーキわからんかった人のためのオニオンアーキテクチャ」というZenn記事を書いて，反響が大きかったのでリメイクしたいなという気持ちになり執筆することにしました． 前回同様，調べていく上で誤解していた部分や理解しにくかった部分を語った上で，オニオンアーキテクチャという，クリーンじゃないけどクリーンみたいな玉ねぎについて紹介するのですが，今回はわかりやすい図解であったり，実際にどのような実装をしていくべきなのかを話の話題として加えていければ良いかな？って思っています． これは前回の記事である「クリーンアーキわからんかった人のためのオニオンアーキテクチャ」の記事の裏話的な話を一つさせてください． 今年の11月初め頃に，サポーターズという企業の学生が登壇できるLT会があり，私
1日300万件のレコードを処理するアーキテクチャ構成 保育士さんの負担はDesign for Failureな「午睡チェック」でサポート
スタートアップのエンジニアの交流や知見の共有を目的とする、AWS Startup Community 主催の技術系オンラインイベント「AWS Startup Tech Meetup Online #5」。ここでユニファ株式会社の赤沼氏が登壇。「午睡チェック」の概要とアーキテクチャについて紹介します。 自己紹介 赤沼寛明氏（以下、赤沼）：よろしくお願いしますみなさまこんばんは。ユニファでCTOをしています、赤沼と言います。 今日はAWS Startup Tech Meetupということで、弊社ではプロダクトをすべてAWS上で構築しているんですが、その中でも「ルクミー午睡チェック」というサービスがありまして。その中でDynamoDBやSQSというのを活用してるところがあるので、主にそのあたりにフォーカスして紹介したいと思っております。 まず簡単に自己紹介します。私は6年前、2015年に1人目の
Clean Architecture on Frontend （翻訳） - Qiita
こちらはDEV Communityに2021年9月2日に投稿され、現在反響を巻き起こしているフロントエンドにおけるクリーンアーキテクチャの実装についてのAlexさんの記事になります（原文はこちら)(twitterにて翻訳掲載許可取得済み）。 かなり大ボリュームな超大作記事となっておりますが、Reactなどを使ったフロントエンドプロジェクトのディレクトリー構成やファイルごとの責務の切り分けのベストプラクティスなどの決定版といえるものがまだまだ出てこない中で、個人的にまさに待ち侘びていたような内容の記事かと思い、是非日本のフロントエンドコミュニティでも知見が共有されればと思いました。 それでは以下、本文です。 *翻訳は大部分をDeepL翻訳によって行っていますが、適宜修正してあります。 少し前に、私はフロントエンドにおけるクリーンアーキテクチャについての講演を行いました。この記事では、その講演
ビジネス・アーキテクチャとシステム・アーキテクチャ - Runner in the High
うちのコンサルが「システムアーキテクチャを決めるためには、ビジネスアーキテクチャを先に固めることが必要」と言ったら、お客様が「事業構造の変化が激しすぎてビジネスアーキテクチャを固めることが難しい」と仰った。 そうだよなぁ。システムの寿命よりビジネスの寿命のほうが短くなってるのかも— ボム / SIer (@bombombomb2017) 2021年8月29日 これにめちゃくちゃ共感した。 よくあるアーキテクチャ設計では、ドメイン層と応用層を分離することで応用層におけるコントロール不能な変化をドメイン層に及ばないようにさせたりする。しかし、現実のプロダクト開発ではDBやフレームワークなどの応用層で起きる変化よりもドメイン層の変化のほうが圧倒的に多い。システムにおけるすべての中心にあり、あらゆるところから依存されているドメインが頻繁に変化するとなると非常にツライ。 とはいえ、ビジネス・アーキテ
クリーンアーキテクチャなんてものはない(クリーンアーキテクチャーの読み方)
すでに何人かの人がクリーンアーキテクチャなんてないよ、って話はしていてイマサラだと思うんですが。 あえてブログの記事に残そうかなと思って書いてみます。 最近、改めてクリーンアーキテクチャ本を読んだり、原文を読んだり、 ここ数ヶ月ツイート色々な人のを観測したり社内で話したりしていて 考えがまとまってきたので、自分の言葉で整理してみたくなった。 「へー、クリーンアーキテクチャっていうソフトウェアアーキテクチャがあるんだー」という微妙な誤解？をちょっとでも減らす一助になればという感じです。あと、本の読み進め方のヒントにもなるかも 先に結論 クリーンアーキテクチャというのはアンクルボブの書いた本。 ソフトウェアアーキテクチャのことではない。 the クリーンアーキテクチャというブログ記事はただのソフトウェアアーキテクチャの例(そして本の一部分)だが、独り歩きしている クリーンアーキテクチャというソ
Architecture as Codeってなぁに？ 〜Infrastructure as Codeを超えて〜 - NRIネットコムBlog
こんにちは、最近Alexaに好きな音楽を伝えるとそればっか再生されて飽きてきたので、どうAlexaに伝えれば傷つかないかを考えている志水です。 「APN AWS Top Engineers/APN Ambassadors Week」の3日目の記事になります。といっても、特にTop Engineerに関係ない話をします。 Architecture as Codeという言葉をご存知でしょうか？2019年のAWSのブログでArchitecture as Codeという言葉が出て、そこから一部のマニアックな方が言及されているのですが、イマイチ浸透せず可愛そうな状況になっています。個人的には面白い概念だと思い、かつ最近Architecture as Codeの概念を継承しているサービスのAWS Copilot/AWS Amplifyが盛り上がっているため、改めてまとめようと思います。 Infrast
サーバーレスが気になる開発者に捧ぐ「べき等性」ことはじめ 第一回〜べき等性 (冪等性/idempotency) ってなんだ!? - builders.flash☆ - 変化を求めるデベロッパーを応援するウェブマガジン | AWS
そもそも、べき等性とは、どういうことを言うのでしょうか ? これは「ある操作を 1 回行っても複数回行っても結果が同じである」ことをいう概念です。 例えば、注文処理を考えます。画面インターフェースで、注文確定 / 送信ボタンを押すという操作で二度三度押してしまうユーザーがいます。これで同じ内容の注文が複数回登録されてしまったら問題です。こういったケースでは、画面側で連続して押せないような実装を追加したり (①)、サーバー側で同じ注文の処理であることを認識して適切に一つの処理と判断するようなこと (②) が必要です。 この例では、画面側の制御を入れたほうが簡単なように見えます。しかし、現実には画面とサーバーとの間のネットワークの問題や画面以外からの HTTP コールなどを考えると、このような重複リクエストが起こってしまうという可能性はゼロではありません。 このようなものへの対処として、サーバ
クリーンアーキテクチャ完全に理解した
clean_architecture.md 2020/5/31追記: 自分用のメモに書いていたつもりだったのですが、たくさんのスターを頂けてとても嬉しいです。 と同時に、書きかけで中途半端な状態のドキュメントをご覧いただくことになっており、大変心苦しく思っています。 このドキュメントを完成させるために、今後以下のような更新を予定しています。 TODO部分を埋める 書籍を基にした理論・原則パートと、実装例パートを分割 現在は4層のレイヤそれぞれごとに原則の確認→実装時の課題リスト→実装例という構成ですが、同じリポジトリへの言及箇所がバラバラになってしまう問題がありました。更新後は、実装時の課題リストを全て洗い出した後にまとめて実装を確認する構成とする予定です。 2021/1/22追記: パートの分割と、クリーンアーキテクチャという概念の定義について追記を行いました。大部分の実装例パートを中心
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
データベースの仕組み(アーキテクチャ)をざっくり理解する
電子情報学特論：Chromiumのアーキテクチャを解き明かす
マイクロサービス・アーキテクチャと共存する Ruby on Rails のアーキテクチャ的拡張 - その事例と可能性 / Kaigi on Rails 2021
GraphQL を利用したアーキテクチャの勘所 / Architecture practices with GraphQL
