サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
こんにちは、Dapr Advent Calendar 8日目です。今週は会社で全エンジニアとの1 on 1などやっており、なかなかの忙しさなのですが、何とかブログを続けられています！ DaprとZipkinで分散トレーシングをしてみよう 今回はDaprとZipkinを使って分散トレーシングをしてみます。最近色々なサービスやミドルウェアが分散トレーシングに対応するようになったので、だいぶ世の中に認知される技術になりましたよね。使ってるかどうかは別として😏 分散トレーシングやZipkinについての解説をすると長くなるので、あまりご存じないという方は先に調べておいてくださいね。 今回作成するアプリケーションのソースコードはgithubに置いてあります。 https://github.com/cero-t/dapr-advent-2021/ 今回は、過去に作成した「hello」「publish」
読破した分厚いオライリー本の感想記事です。本書ではCPUの速度がボトルネックになるようなものは演算指向アプリケーションと区別し、データの量や複雑さ、変化の速度が主題となるシステムを「データ指向」と位置づけて、特定技術に幅を狭めずに包括的に解説した本となっています。 著者はイギリス、ケンブリッジ大学の分散システムの研究者 Martin Kleppmann氏。監訳者が斉藤太郎氏、訳者は玉川竜司氏。 タイトルの『データ指向アプリケーションデザイン』の原題は Designing Data-Intensive Applications。よく使われる「オブジェクト指向」の原語は Object-Oriented ですが、本書の「指向」は Intensive で若干ニュアンスが違います。たまに見るデータ駆動、データドリブンなどともちょっと違いますね。 Intensive単体の意味は強い、激しい、徹底的、集
監訳者の@taroleoさん経由で発売前に頂いたのですが、分量が多く（約600ページ）内容もぎっしりで読むのに時間がかかってしまいました。紙媒体のものを希望してお送り頂いたのですが、あまりの厚さに持ち運びが困難なので電子版にすればよかったと若干後悔しました…。 データ指向アプリケーションデザイン ―信頼性、拡張性、保守性の高い分散システム設計の原理 作者: Martin Kleppmann,斉藤太郎,玉川竜司出版社/メーカー: オライリージャパン発売日: 2019/07/18メディア: 単行本（ソフトカバー）この商品を含むブログを見る 近年クラウドの発展に伴い、小規模なアプリケーションといえども分散データシステムに関する知識が不可欠になってきました。AWSなどのクラウドプラットフォームでは手軽に分散ストレージや分散データベースを利用することができますし、WebアプリケーションとRDBを使う
『データ指向アプリケーションデザイン』を読んだ。たいへんおもしろかった。技術書でこんなにわくわくしながら一気に読んだのは『Androidを支える技術』以来かもしれない。 データ指向アプリケーションデザイン ―信頼性、拡張性、保守性の高い分散システム設計の原理 作者: Martin Kleppmann,斉藤太郎,玉川竜司出版社/メーカー: オライリージャパン発売日: 2019/07/18メディア: 単行本（ソフトカバー）この商品を含むブログを見る本書はソフトウェアシステムの設計について「データ」という観点からまとめたものだ。もちろんデータベースは登場するが、それだけでなくJSONなどのデータ形式、RPC、メッセージキュー、全文検索インデクス、バッチ処理やオンライン処理も等しく「データ」という観点から扱っている。特筆すべき点は、理論だけでなく実際のミドルウェア製品を引き合いに出しつつ具体例を
あけましておめでとうございます（いまさらｗ）。もーすけです。 最近は呪術廻戦にハマっています。ぜひまだ見てない方見てみてください！ さて本題ですが、新年はじめの投稿はデータ指向アプリケーションデザインという書籍についてです。 最近読んだ中で一番良かった本ではないかと思っています。 実は、勤めている会社内でこの書籍の輪読会を行っていて、自分が12章（最終章）を担当しました。 12章はこの本の一番言いたいことが書いてある章でもあったので、本の魅力を理解してもらうのにもしかして役立つのでは！？と思い、この書籍の紹介しつつ、輪読会で発表した内容を動画で解説していきたいと思います。 どんな本なのか？ もしかしたら本のタイトルから「データエンジニアとかデータサイエンスの人とかよむ本かな？」と思ってしまうかもしれません（自分は最初ちょっとそうおもってましたｗ）。しかし、この本は 「信頼性があり、スケーラ
自分が所属している会社のメンバーの教育用資料として、それなりの規模のデータを扱う時に前提として意識しておかなければいけないことをざっくりまとめたので、弊社特有の話は除外して公開用に整理してみました。 大規模データ処理、分散処理に慣れている人にとっては今更改めて言うことじゃないだろ、みたいな話ばかりだと思いますが、急激にデータスケールが増大してしまったりすると環境に開発者の意識が追い付かないこともあるかと思います。 そういったケースで参考にできるかもしれません。 弊社は基本的にAWSによって運用されているので、AWSを前提にした様なキーワードやサービス名が出てきます。後、句読点があったり無かったりしますが、ご容赦ください。 追記: 社内用の資料の編集なのでかなりハイコンテキストな内容だから誤解するかもしれませんが、これらはそもそもRDBの話ではありません。(関係無くは無いけど) 1000万オ
TL;DR 分散システムにおいてキューを導入する場合、本当にキューが必要なのか再考すべき。そこが地獄の入り口だから。 システムの抽象 コンピュータの世界は、本来は0と1の信号の羅列が飛び交う無機質なものである。でも人類は信号だけですべてを語らず、様々な喩えを定義してきた。それはデスクトップ・ウィンドウ・マウスカーソルといったグラフィカルな表現に留まらず、パケットやカプセル化といった用語にロック・キュー・リスト・木などのアルゴリズムやデータ構造の世界にも自然に溶け込んでいる。これらはすべて人間の理解を助けるための喩え話に過ぎず、この喩えこそが人間のより直感的な理解をもたらす一方で、発想の制約を生み出してきた。 人間が大きなシステムを作るときも何らかの喩えを用いてシステム全体を整理する。アーキテクチャの「ポンチ絵」を描いて情報共有をするのは企業に勤めていれば経験した人も多いだろう。パワーポイン
(This post is also available in English.) この記事はLinux memory management at scale を 著者の Chris Down さんの許可 を得て Hiroaki Nakamura が日本語に翻訳したものです。 原文のライセンス は CC BY-SA 4.0 であり、翻訳のライセンスも同じく CC BY 4.0 とします。cgroup2プロジェクトでの私の仕事の一部としてLinux システムのリソース管理についてエンジニアと話すことに多くの時間をかけてきました。 これらの会話を通じてどんどん明らかになってきた 1 つの事実は多くのエンジニアは、シニア SRE たちでさえも、Linux のメモリ管理についていくつかのよくある誤解を持っていて、そしてそれが彼らがサポートするサービスやシステムが本来確実に稼働したり効率的
What is DistributedSQL?DistributedSQL is a category of relationaldatabases that combines the core features of traditionalSQL and NoSQL systems, being strongly consistent while natively providing ACID transactional support across data centers, availability zones, and regions—in the cloud.It provides a singlelogical relationaldatabase deployed across a cluster ofnetwork servers. Distributed
AmazonでMartin Kleppmann, 斉藤 太郎, 玉川 竜司のデータ指向アプリケーションデザイン ―信頼性、拡張性、保守性の高い分散システム設計の原理。アマゾンならポイント還元本が多数。Martin Kleppmann… 手軽に扱えるデータの量や種類が増える一方、CPUの性能はムーアの法則通りには成長しなくなり、大規模データ処理では、多数のマシンを活用する分散処理が欠かせなくなってきました。クラウドの普及とともに多数のマシンを自ら調達せずとも分散システムを構築できるようにもなっています。 しかし驚くべきことに、今までこの分野に入門するための定番の書籍がありませんでした。分散処理にデータ処理が加わる融合分野である上、オープンソースプロジェクトの進化も速く、専門家同士でも共通の理解を構築するのが非常に難しかった分野です。この本を上手に使うと、既存のOSSプロジェクトの位置付けや、
こんにちは。Necoプロジェクトの池添(@zoetro)です。Necoプロジェクトでは、自社データセンター上のインフラ構築の仕組みを開発しており、サーバーのプロビジョニング、Kubernetesクラスタの構築、Kubernetes上で動くアプリケーションのデプロイ、各種ソフトウェアやOSのアップグレードなどをすべて自動化しています。blog.cybozu.io このプロジェクトでは「データセンターの機能をすべてテストすること」を設計方針のひとつとしており、データセンターをまるごと仮想化してテストし、人の手を介することなく成果物の継続的インテグレーションとデリバリーを実現しています。 最初にこの方針を決めたとき、チーム内でも議論がありました。本当にデータセンターをまるごと自動テストできるのか？QAチームの手動テストをおこなわずに品質を保証することができるのか？など多くの疑問が湧きました。
Apache Igniteは、Apache Sparkと同様にインメモリ技術を活用した高耐障害性分散データ処理プラットフォームです。 しかし、Apache Sparkは非トランザクション(バッチ)的な分析を処理の対象をしている一方、Apache Igniteはリアルタイム処理に優れ、非トランザクションとACIDトランザクション的な処理を両方サポートします。 この2つのプラットフォームを組み合わせて使うことには大きなメリットがあり、2つの統合のための機能がApache Igniteには早期開発段階から導入されました。本稿では、Apache Ignite + Apache Sparkの統合はどういう風に実現されたか、既にSparkを使ってデータ処理を行うシステムへIgnite導入のメリットについて説明します。 はじめに Apache Ignite（以下、Ignite）は、メモリを中心に据えた
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフーTechBlog Apache Ignite導入の体験レポート Roman Shtykh (Data and Science Solutions Group, Apache Ignite committer) @rshtykh Toru Yabuki（Shopping Services Group, Commerce Company）Yahoo!ショッピングは、ユーザが買い物を楽しむために様々なサービスを提供する日本最大級のEコマースプラットフォームです。本稿では、Apache Igniteを用いて、階層を持つカテゴリーなどで絞り込みながらたった今売れた商品を取得できるサービスを刷新した事例を紹介します。スケールアウトするApache Ignit
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフーTechBlog こんにちは！ 大阪開発本部の太郎良です。 普段は社内プラットフォームの開発をしていますが、副業制度を利用してブロックチェーン関係の仕事もしています。 今回はブロックチェーンを使用した分散型アプリケーション(DApps)について情報を整理しつつ、所属しているヤフーでの可能性を考えてみました。 ※投稿内容は私個人の意見であり、所属企業・部門見解を代表するものではありません。 DAppsについて DAppsって何？ DApps(Decentralized Applications)とは、分散型アプリケーションのことです。 DAppsに投資するVCのDavid Johnstonらによって次のように定義されています。 アプリケーションはオー
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
