[レポート]みんなの考えた最強のデータアーキテクチャ #datatechjp | DevelopersIO
さがらです。 11月8日20時～22時に、datatech-jp(データエンジニアリング関係のコミュニティ)主催でみんなの考えた最強のデータアーキテクチャというイベントが開催されました。 本記事はこのイベントのレポートブログとなります。 イベント概要 ※connpassより引用 datatech-jpで集ったデータエンジニアが、それぞれみんなの考えた最強のデータアーキテクチャを紹介し合うという夢のような企画が実現しました！ たくさんの新しいプロダクトが群雄割拠する現在、モダンデータスタックなどという言葉も登場しています。 今こそ、どんなプロダクトを選び、どのようなデータ基盤を作れば、効率的にやりたいことが実現できるのか。 5人の猛者からおすすめの構成をご紹介いただきながら、参加者のみなさんとも一緒に考えていく時間としたいと思います。 おまけ：当イベントの応募者数 このイベントですが、なんと
![[レポート]みんなの考えた最強のデータアーキテクチャ #datatechjp | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/9f9486832be1a42a11ac2d244e8c51de11a34ab7/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2022%2F11%2F2022-11-08_19h35_04.jpg)
React で作る中規模 SPA のレイヤードアーキテクチャ - GiXo Ltd.
TAG : Advent Calendar | Firebase | Firestore | React | Refeed | TypeScript | トチカチ | フロントエンド AUTHOR : ギックス POSTED : 2020.12.23 08:25 この記事は GiXo アドベントカレンダー の 23 日目の記事です。 昨日は、少人数の開発で Kubernetes を活用するための設計戦略 でした。 MLOps Div. の堀越です。本記事では、React と TypeScript で SPA の実装を行う際に採用しているレイヤードアーキテクチャについてご紹介します。 レイヤードアーキテクチャというとクリーンアーキテクチャや DDD が有名ですが、弊チームフロントエンド の場合はクリーンアーキテクチャから SPA にマッチする箇所を部分的に取り入れた簡易版のレイヤードア
Microservices分割大全 - kawasima
Microserviceの分割の仕方について語られているものを収集します。 microservices.ioのサイトに載っている分割パターンは4つ。ただし「自己完結型サービス」と「チームごとのサービス」は、直交していないので大きくは「ビジネスケイパビリティでの分割」と「サブドメインでの分割」の2つ。 ビジネスケイパビリティでの分割 https://microservices.io/patterns/decomposition/decompose-by-business-capability.html 現在の業務機能にしたがってサービスを分割する。 したがって、コンウェイの法則にしたがった分割とされる。 サブドメインでの分割 https://microservices.io/patterns/decomposition/decompose-by-subdomain.html DDDのサブドメ
データ収集の基本と「JapanTaxi」アプリにおける実践例
1. Mobility Technologies Co., Ltd. Data Engineering Study #2 データ収集の基本と 「JapanTaxi」アプリにおける実践例 株式会社 Mobility Technologies 渡部 徹太郎 2020/8/19 2. Mobility Technologies Co., Ltd. 自己紹介 2 ID ：fetaro 名前：渡部 徹太郎 学生：東京工業大学でデータベースと情報検索の研究 (@日本データベース学会) 職歴： * 野村総合研究所(NRI) - オンライントレードシステム基盤 - オープンソース技術部隊 * リクルートテクノロジーズ - ビッグデータ分析基盤 * MobilityTechnologies - データエンジニア エディタ：emacs派→ InteliJ派 日本AWSユーザ会(JAWS) ビッグデータ支部長
理解して拡げる分散システムの基礎知識
20200725の #JTF2020 セッションスライド。 （資料内で説明した資料へのリンク） ・昨年のJTF発表資料 https://speakerdeck.com/tzkoba/cloud-nativekai-fa-zhe-falsetamefalsedatabase-with-kuber…
「The Twelve-Factor App」を15項目に見直した「Beyond the Twelve-Factor App」を読んだ - kakakakakku blog
2012年に Heroku のエンジニアによって提唱された「The Twelve-Factor App」は素晴らしく，アプリケーションをうまく開発し，うまく運用するための「ベストプラクティス」として知られている．2020年になった現在でもよく引用されていると思う．日本語訳もある． 12factor.net Beyond the Twelve-Factor App とは？ クラウド化が進むなど，提唱された2012年と比較すると技術的な変化もあり，今までの「The Twelve-Factor App」で宣言されていた観点以外にも必要な観点やベストプラクティスがあるのでは？という意見もある．そこで，2016年に Pivotal のエンジニアが「Beyond the Twelve-Factor App」を提唱した．The Twelve-Factor App にあった「12項目をアップデート」し，新
一枚岩のシステムを解体 徐々にマイクロサービスへ
日経クロステック Activeは、IT／製造／建設各分野にかかわる企業向け製品・サービスについて、選択や導入を支援する情報サイトです。製品・サービス情報、導入事例などのコンテンツを多数掲載しています。初めてご覧になる際には、会員登録（無料）をお願いいたします。
ソフトウェアアーキテクチャを学ぶために - kawasima
いわゆるGoFの23個のデザインパターン。知っておくに越したことはないが、フレームワーク・ライブラリに溶け込みすぎていて、現代では知らないうちに使ってることになるので、余裕があれば。
ここまでできる ! 設定ファイルからの ネットワーク構成可視化 / OSC2019_Tokyo_Enterprise
オープンソースカンファレンス2019 OSC2019.Enterprise https://www.ospn.jp/osc2019.enterprise/
メルペイのマイクロサービスアーキテクチャの裏側と、不整合を防ぐための工夫
2019年7月24日、ヤフー株式会社が主催するサーバーサイドエンジニア向けの勉強会「Bonfire Backend #3」が開催されました。第3回となる今回のテーマは「モバイル決済の裏側」。急速に成長するモバイル決済分野でサービスを展開する企業が一堂に会し、自社サービスの仕組みや技術スタックなど、知られざる裏側を語ります。プレゼンテーション「静的MPM決済を支える技術 」に登壇したのは、株式会社メルペイのsusho氏。今年の6月にサービスが開始したばかりのメルペイのサーバーサイドの特徴と工夫について語ります。 静的MPM決済を支える技術 susho氏：こんばんは。「静的MPM決済を支える技術」ということでsushoが発表させていただきます。 最初に自己紹介です。 社内ではsushoと呼ばれているので、ここでもそうさせていただいております。Twitterは@susho0220でやっています。
秒間100万リクエストをさばく - Googleの共通認可基盤 Zanzibar - 発明のための再発明
はじめに Googleの提供するサービス郡が共通して利用している認可システムにはZanzibarという名前がついています。ZanzibarはGoogleDrive・Google Map・Youtubeなどの巨大なサービスにも使用されています。 そのため、利用量も凄まじく 数10億のユーザー 数兆のACL(access control list) 秒間100万リクエスト もの量をさばいています。 にも関わらず、Zanzibarはこれを10ミリ秒以内に返します(95パーセンタイル)。 この記事では、そんなZanzibarの内部構造に関する論文「Zanzibar: Google’s Consistent, Global Authorization System」の中から、主に大量のリクエストをさばくための工夫を紹介します。 ちなみに、以前Googleの社内システム用の認可システム「Beyond
モダンBFFを活用した既存APIサーバーの再構築 - クックパッド開発者ブログ
技術部の青木峰郎です。 去年までは主にデータ分析システムの構築を担当していましたが、 最近はなぜかレシピサービスのサービス開発をやっています。 今日は、そのサービス開発をする過程で導入したBFF（Backends for Frontends）であるOrchaについて、 導入の動機と実装の詳細をお話しします。 Orcha導入にいたる経緯 まずはOrcha導入までの経緯、動機からお話ししましょう。 最初のきっかけは、わたしが去年から参加しているブックマークのようなサービスの開発プロジェクトでした。 このプロジェクトの実装のために新しいmicroserviceを追加することになったのですが、 そのときにいくつかの要望（制約）がありました。 1つめは、撤退するとなったときに、すぐに、きれいに撤退できること。 2つめが、スマホアプリからのAPI呼び出し回数はできるだけ増やしたくない、という要望です。
Clean Architectureは全てのプログラマにお奨めしたい良著｜erukiti
Clean Architecture 達人に学ぶソフトウェアの構造と設計を読んだので、まとめてみます。コメントやツッコミなどのフィードバックがあればうれしいです。 続編としてクリーンアーキテクチャ本を読むためのポイントという記事を書きました。併せてご覧ください。 なぜ良著？著者のロバート・Ｃ・マーチン（著書読んだことあるかも？）は、50年前から現代に至るまで、様々なアーキテクチャを見て、第一線級として開発し続けてきた経験を元に、どのアーキテクチャでもクリーンにしようとするなら、基本部分は変わらないと言ってて、それらが美味くまとまった本だからです。 いってみればコンピュータ工学について抑えるべきポイントを解説した本であり、The Clean Architectureそのものについてはほとんど割かれていません。それくらい、基本として知るべき事が書かれた本なのです。 最近のアーキテクチャを追いか
開発者向けの基盤をつくる
ハッカーズチャンプルー2019（ http://hackers-champloo.org/2019 ）の発表資料です
飛び込もう、Cloud Nativeの世界
CloudNative Days Fukuoka 2019のKeynoteで発表した資料です。 『クラウドネイティブとは？』と、改めて意味を考えてみました。 その上で、どうやってクラウドネイティブを取り入れていくべきかを解説します。 (CC BY-SA 2.0)
メルカリは開発組織を拡大するためにマイクロサービスアーキテクチャを採用した（前編）。Mercari Tech Conf 2018
2013年から2017年のあいだ、スタートアップを含む2000以上の組織に対して、いかに組織のパフォーマンスを加速するかという聞き取り調査を行い、その調査結果をまとめたものです。 その調査結果のひとつにこのグラフがあります。 これは組織のエンジニアの人数とそのパフォーマンスを、組織の違いによって示したものです。 横軸がエンジニアの人数、縦軸はエンジニアあたりの1日のデプロイ数を指標としたパフォーマンスです。 これによると、パフォーマンスの低い組織はエンジニアが増えるとデプロイ数も減少しています。普通のパフォーマンスの組織はエンジニアが増えてもデプロイ数に変化はありません。 一方でパフォーマンスの高い組織はエンジニアが増えるほど指数関数的にデプロイ数が増えていきます。メルカリが目指しているのはここです。 これは単純にアーキテクチャをモノリシックからマイクロサービスへ移行するだけでは実現できま
サーバレス時代におけるヘテロジニアス時系列データベースアーキテクチャ - ゆううきブログ
この記事は、第2回ウェブシステムアーキテクチャ研究会の予稿です。 ウェブシステムをモニタリングするために、高可用性、高書き込みスケーラビリティ、メトリックの長期保存が可能な時系列データベースが求められている。 これらを実現するために、性能特性の異なる汎用Key-Value Store(以下KVS)を組み合わせ、透過的に問い合わせ可能な、ヘテロジニアス時系列データベースであるDiamondを開発した。 この記事では、Diamondを分散システムの観点で捉え、アーキテクチャ、データ構造、実装を紹介し、考察によりFuture Workを議論する。 1. はじめに 2. アーキテクチャ アーキテクチャ概要 動作フロー データ構造 KVSの機能要件 3. 実装 実装概要 KVS間のデータ移動 データ位置の解決 費用特性 4. 考察と今後の課題 Diamondの欠点 将来機能 5. まとめ スライド
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
アーキテクトに求められるマインドとは / mindset for an architect
The Twelve-Factor App on AWS
GithubエンジニアリングがMySQL高可用性のために新しいアーキテクチャを採用
