Redisは多彩なデータ構造をもつ1インメモリDBであり、昨今のWebアプリケーションのデータストアの一つとして、広く利用されている。 しかし、一方で、性能改善のための手法を体系的にまとめた資料が見当たらないと感じていた。 実際、最初にCPU負荷が問題になったときにどうしたものかと悩み、調査と試行錯誤を繰り返した。 そこで、この記事では、自分の経験を基に、RedisサーバのCPU負荷対策を「CPU負荷削減」「スケールアップ」「スケールアウト」に分類し、パターンとしてまとめる。 背景 RedisのCPU負荷対策パターン CPU負荷削減 multiコマンド Redisパイプライニング Luaスクリプティング Redisモジュール(夢) スケールアップ スケールアウト 参照用スレーブ 垂直分割 水平分割 Redis Clusterによる水平分割 その他 スライド資料 あとがき 参考資料 背景 R
［速報］AWS、クラウド障害をわざと起こす「AWS Fault Injection Simulator」発表。カオスエンジニアリングをマネージドサービスで実現。AWS re:Invent 2020
Amazon Web Services（AWS）は、開催中のオンラインイベント「AWS re:Invent 2020」で、アプリケーションに対してクラウド障害のシミュレーションを行える新サービス「AWS Fault Injection Simulator」を発表しました。 クラウド上で稼働するアプリケーションの耐障害性などを高めるために実際にクラウド障害をわざと発生させて問題点をあぶりだす手法は、「Chaos Enginieering（カオスエンジニアリング）」と呼ばれています。 Netflixが2012年にカオスエンジニアリングのためのツール「Chaos Monkey」を公開したことで広く知られるようになりました。 参考：サービス障害を起こさないために、障害を起こし続ける。逆転の発想のツールChaos Monkeyを、Netflixがオープンソースで公開 今回発表された「AWS Faul
分散システムの一貫性に関する動向について
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog システム統括本部アーキテクト室 今野です。 昨年は、Twitter,Facebookを始めとするクラウド各社で新規の分散システム開発のプロジェクトが相次いで発表された年でした。これらの新しい分散システムを開発する理由や、その背景にあるものは何なのでしょうか？ 今回は、昨年末に開催された高信頼性分散システム系の国際学会であるSRDS 2014[1]の発表内容に関連する論文の話題も踏まえて、昨今のクラウド各社の分散システムの動向について整理してみます。 分散システムにおけるクラウド各社の動向 近年の分散データベースの世界では、AmazonのDynamo[2]やFacebookのCassandra[3]などを代表とする結果整合性（Eve
自分が本格的に設計を意識するようになったのは、2015年の夏に現職であるFringe81株式会社で開催されていたサマーインターンに参加してからだ。 インターンではDDDとクリーン・アーキテクチャ*1を一から勉強してAPIサーバーに実装する、というカリキュラムであったが、いま思うと2週間という比較的長いインターンで僕が学べたことと言えば本当に微々たるものだった。つまるところ、それくらいには設計というものは奥が深い。常になんらか特定のデザイン・パターンなりアーキテクチャ・パターンを適用することでアプリケーション開発がうまくいくということはなく、それらの様々な知識から少しづつ応用されたものが最終的なアプリケーションの設計に対して真の洞察を与えてくれるものというのが、僕自身のいまの認識である。 設計はまさに Connecting the dots そのものだ。多くを知れば知るほど、アプリケーション
バッチ処理について考える - Qiita
TL;DR ひとくちにバッチといっても色々ある 夜間バッチをもう作るな オンラインバッチはSQL以前にDB設計がんばれ はじめに Twitterのタイムラインで以下のようなツイートが回ってきました。 バッチ処理をみんな舐めてかかったり、ショボイとか思ってる人多い印象なんだけれども、数十万～数千万件規模のデータを処理したことあるのかな。テンプレ通りのコードじゃ動かないよ？ネットに本にも答え載ってないよ？低レイヤも意識しないと動かないよ？ 2020年1月10日 ツイートされたわだっしーさんの意図がどこにあるかは確認してないですが、極限の世界でテンプレート的な処理では対応出来ないのはあるよな、と思いつつもある程度はバッチの作法としての書き方があると思っています。 このツイートとその関連ツイートを読みながら、そういえばバッチ処理に関して書いてある記事はあまり見ないなぁ、とおもったので他のネットや本
キーポイント For object-oriented design we follow the SOLID principles. For microservice design we propose developers follow the “IDEALS”: interface segregation, deployability (is on you), event-driven, availability over consistency, loose-coupling, and single responsibility. Interface segregation tells us that different types of clients (e.g., mobile apps, web apps, CLI programs) should be able to inte
トランザクション分離レベルの古典的論文 A Critique of ANSI SQL Isolation Levels を読む - Hatena Developer Blog
こんにちは、 id:alpicola です。今年4月に新卒入社してアプリケーションエンジニアとして働いています。 ウェブアプリケーションはその性質上、データベースに対して同時に大量の問い合わせを行います。そうした中でデータベースが個々の問い合わせを処理していくときに起こっていることは何か、どういう順序で処理が行われるのか、というのは興味深い話題かと思います。例えばデータベースに対して行った更新処理の結果が、更新を行ったクライアント以外のクライアントからも「見える」ようになるのはいつでしょうか。入社間もない頃、先輩エンジニア達にそうした疑問をぶつけてみたところ、「トランザクション分離レベル」というキーワードと、この分野の古典的な論文 A Critique of ANSI SQL Isolation Levels を教えてもらい、輪読会を社内で開催しました。この記事ではこの輪読会の模様をレポー
はじめに こんにちは！yamakazu (@yamarkz) です。 近所の行きつけスーパーがサミットストアになったのですが、品揃えがとても良く、お店の雰囲気も明るくて、仕事終わりの買い物が最近の楽しみになってます 🥳 🛒🥗 さて今回は、開発方面のナレッジとして外部API連携の話を紹介します。非常にニッチな領域の話題ですが、わかる人にはわかるような内容です。 興味のある方はぜひ最後まで読んでみてください。 動機 新しく外部API連携の開発に着手するメンバーの助けになりたい、より良い外部API連携を実現したいという思いから、これまで開発を経験してきた中で理解した勘所を紹介します。 元々は社内向けに書き溜めておいたナレッジメモの内容ですが、特別社内に留めておく必要性もないので、せっかくならブログにしてしまおうと思い、ここで筆を取りました。 これは社内の同僚に向けた内容でありながら、似た境
NewSQLはデータベースに革命を起こすか - NetflixにおけるCockroachDBのユースケース｜ミック
近年のデータベースの新潮流にNewSQLと呼ばれる一群のデータベース製品群の登場がある。そのコンセプトを一言でいうと、RDBとNoSQLのいいとこどりである。SQLインタフェースと強いデータ一貫性（ACID）というRDBの利点と水平方向のスケーラビリティというNoSQLの長所を兼ね備えた夢のようなデータベースである。下図に見られるように、RDBとNoSQLが鋭いトレードオフを発生させていたのに対して、NewSQLではそれが解消されているのが分かる。 RDB vs NoSQL vs NewSQL本当にそのような夢の実現に成功しているか、というのはまだ議論が続いているが（クエリのスループットを出すためにレイテンシを犠牲にしているので本当にトレードオフを解消はしていない、などの問題が指摘されている）、商用でも利用可能な製品としてGoogle Spanner、TiDB、YugabyteDB、Coc
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは、データ＆サイエンスソリューション統括本部所属の後藤泰陽（@ono_matope）です。少し時間があいてしまいましたが、9月19日にお茶の水女子大学で開催された WebDB Forum 2017 において、分散オブジェクトストレージ “Dragon” について講演しました。良い機会なので、本エントリでもDragonについてご紹介させていただきたいと思います。 発表資料 WebDB Forumでの発表資料については以下をご覧ください（講演時の内容と一部異なります）。 日本語版 Dragonとは？ Dragonは、ヤフー・ジャパンで開発された分散オブジェクトストレージシステムです。Amazon S3互換のWeb APIを実装
分散システムについては、もう随分と前から学びたいと思っていました。ただ、それは一度首を突っ込んだら最後、ゴールのない迷路に迷い込むようなものなのです。どこまでも続いているウサギの穴のようなものです。分散システムに関する文献は星の数ほど存在します。様々な大学からたくさんの論文が発表されているばかりでなく、膨大な数の書籍もあるのです。私のような全くの初心者には、どの論文を読んだらいいのか、どの書籍を買ったらいいのか、見当もつきません。 そんなとき、一部のブロガーが、 分散システムエンジニア （それがどういう意味であれ）になるなら知っておくべき論文というものを推奨しているのを見つけました。その一部を紹介しましょう。 FLP , Zab , Time, Clocks and the Ordering of Events in a Distributed Systems , Viewstamped
NoSQL登場の背景、CAP定理、データモデルの分類
その例としてBeck氏自身が過去に取り組んできた生命保険会社のアプリケーションを例に挙げます。そのアプリケーションでは毎日のようにスキーマが変化するため、SQLとORM(Object-Relational Mapping）では対応できず、オブジェクトデータベースのGemstoneを利用することで対応できたと述べています。 こうしたSQLだけでは満たせないさまざまな要件、上記の図にあるようにスキーマの可塑性、スケーラブルなデータ読み込み、書き込み、処理の柔軟性などを満たすために、リレーショナルデータベース以外のNoSQLな製品が開発された。これがNoSQLの登場の背景にあるとBeck氏は解説します。一方で、こうしたさまざまなNoSQLを、NoSQLという言葉で表すのは適当ではないという憂慮も示しています。 Here is where the futility of defining NoSQ
Facebookが15日に発表した新しいサービス「Facebook Messages」は、チャットやつぶやき、そして電子メールなど、自分宛のテキストやメッセージをすべて1つのインボックスで管理できると発表されました。 同社が15カ月かけて開発してきたこの新サービスのバックエンドデータベースは、これまで同社が大規模運用してきたMySQLでも、同社が開発したNoSQLデータベースのCassandraでもなく、グーグルのBigTableをモデルとしてオープンソースで開発された分散データベース「HBase」でした。 Facebookのソフトウェアエンジニア、Kannan Muthukkaruppan氏がFacebookにポストした記事「The Underlying Technology of Messages」で、その技術的背景が紹介されています。 MySQLとCassandraが落選した理由 H
これは Aizu Advent Calendar 2019 の 15 日目の記事です。14 日目は uzimaru0000 さん、16 日目は kacky__917 さんです。 はじめに 世の中には日々たくさんの価値ある Web サービスが生まれていますが、その価値を正しく提供するにはアプリケーションが正しく動かなければなりません。 たとえばアプリケーションは適切なユーザに適切なリソースを提供しなければならず、エラーを返す際は十分に定義された仕様に沿って返し、UI 側ではユーザに適切なメッセージを表示しなければなりません。 実際のところ、これらを厳密に実現するのは非常に困難ですが、アプリケーションにはこれら以上に複雑な問題が常につきまといます。 現在の Web アプリケーションはほとんどが分散システムの一形態です。例えばクライアントとサーバや、サーバとデータベースがネットワークを介して接続
このブログが話題になってますね。制約を付けること自体はよいことだけど、無目的に適用すると害も生じると思います。 無目的という言い方はおかしいな…。外部キー制約をどのように使えばいいのか、逆にどんなときに使うとまずいのかを考えてみたいと思います。 tech.tabechoku.com 例えば、これ。外部キー制約はできるだけ付けるとか、何も考えずに付けるとよくないと思います。 外部キー制約は、可能な限りつけるようにしています。 DBが別れている場合、外部キーはもちろん貼れないのですが、そうでない場合はとにかく何も考えず貼っています。データベース設計の際に気をつけていること - 食べチョク開発者ブログ テーブル設計をシミュレーションする いいたいことの結論はこれ。以上終了なのですが、もう少しわかりやすく書いてみよう。 何も考えずに外部キーを貼るのは良くないな。トランザクション境界の外で結果整合性
『データ指向アプリケーションデザイン』を読んだ。たいへんおもしろかった。技術書でこんなにわくわくしながら一気に読んだのは『Androidを支える技術』以来かもしれない。 データ指向アプリケーションデザイン ―信頼性、拡張性、保守性の高い分散システム設計の原理 作者: Martin Kleppmann,斉藤太郎,玉川竜司出版社/メーカー: オライリージャパン発売日: 2019/07/18メディア: 単行本（ソフトカバー）この商品を含むブログを見る 本書はソフトウェアシステムの設計について「データ」という観点からまとめたものだ。もちろんデータベースは登場するが、それだけでなくJSONなどのデータ形式、RPC、メッセージキュー、全文検索インデクス、バッチ処理やオンライン処理も等しく「データ」という観点から扱っている。特筆すべき点は、理論だけでなく実際のミドルウェア製品を引き合いに出しつつ具体例を
バックエンドに関する経験があった私は、2年前にモバイルソフトウェアエンジニアとしてUberに入社しました。担当することになった仕事は、決済機能の構築を含む アプリの刷新 です。その後、 技術管理の側に回る ことになり、チームそのものを率いることになります。配下のチームは、決済を行うバックエンドシステムの多くを担当していたため、責任者となった私もバックエンドに触れる機会が以前にも増して多くなりました。 Uberで働く前は、分散型システムの経験はなきに等しかったと言っていいと思います。 それまでの私は、一般的なコンピュータサイエンスの学位を取得後、フルスタックのソフトウェア開発に10年間、関わっていました。分散型システムについては、一応、大まかな仕組みやトレードオフなどは知っていましたが、一貫性や可用性、冪等性などの概念に精通していたとはお世辞にも言えません。 この記事では、大規模で可用性が高
プログラマの思索
astahにタイミング図がサポートされたのでメモ。 【参考】 astah* 9.2リリースノート | astah タイミング図 | astah* 機能ガイド plantumlでタイミング図が描けるらしい: プログラマの思索 astahとPlantUMLを行き来できるastah* PlantUML Pluginが面白い: プログラマの思索 astah* Mermaid Pluginが公開された: プログラマの思索 Timing図 わかりやすくUMLタイミング図とは 【PlantUMLの使い方】PlantUMLでタイミングチャートを作成する - システムとモデリング UMLのタイミング図を使う機会は正直ほとんどないし、経験もない。 感覚的には、シーケンス図を横型にしたイメージを持っている。 ただ、ハードウェア設計者ならタイミング図をよく使うと聞いているので、どんな状況でどのように使うのか、調べ
Pokémon GO が数百万ものリクエストへの対応を実現している方法 | Google Cloud 公式ブログ
※この投稿は米国時間 2021 年 10 月 27 日に、Google Cloud blog に投稿されたものの抄訳です。 ポケモンを捕まえたことはありますか？Pokémon GO は何百万人もの人がプレイする人気ゲームですが、非常に優れたスケーラビリティを実現しています。このブログでは、Pokémon GO のエンジニアリング チームがどのようにこの大規模なサービスを管理し、維持しているのか、その舞台裏を紹介しています。Niantic Labs のシニア エンジニアリング マネージャーで、 Pokémon GO のサーバー インフラストラクチャ チームを率いる James Prompanya 氏に、この大人気ゲームを支える アーキテクチャについてお話を伺いました。動画をご覧ください。 Priyanka: Pokémon GO とは？ James: これは典型的なモバイルゲームではあ
先週の (Emit) カンファレンスでは、卓越した講演の数々、興味の尽きないパネルディスカッションが行われ、サーバレスコミュニティの優秀な仲間たちに出会って貴重な意見交換をする機会がたくさんありました。 そこでは誰もが一様に、コストこそがサーバレス適用の推進の鍵だとみなしていました。オンデマンド実行と生来の弾力性は、稼働率を最適化しつつ、稼動時間と信頼性もさらに高い状態に保ちます。従量課金制はコストを直接的に定量化できるものに変えました。場合によっては 桁外れの 節約 になる可能性があります。パネルディスカッションで、Gartnerのアナリストの Anne Thomas は、企業クライアントは”コスト”が有利という理由からサーバレスに興味を持つ、と話しました。 しかし、クローズドなシステムにフリーランチはありません。メリットを得るには何かを犠牲にしなければならないのです。テクノロジーにおい
スケーラブルなデータベースを実現する手段として「Sharding MySQL plus memcached」がよく知られる方法だとは、1つ前の記事「MySQL+Memcachedの時代は過ぎ、これからはNoSQLなのか、についての議論」で紹介しました。 ちなみに「Sharding」（シャーディング）とは複数のデータベースにデータを分散して運用することで、ざっくりいえばShared Nothing的な分散データベース構成のことです（この記事で紹介する英文中には「Shared MySQL」（共有MySQL）との記述がありますが、これは恐らく「Sharded MySQL」（ShardされたMySQL）のミススペルではないと推測します）。 日本で（たぶん）もっともMySQLについて詳しく解説してあるブログ「漢(オトコ)のコンピュータ道」のエントリ「さらにMySQLを高速化する7つの方法」では、Sh
『画像システムの車窓から』
2年半くらい画像システムを担当していたのですが、3月イッパイで異動することになりましたokzkです。 異動記念ということで、とりとめもなくエンジニアブログを書いてみます。長いです。よろしくお願いいたします。 画像システムのこれまでのストレージ事情最初にアメブロ(以下、単にブログ)のユーザ投稿画像関連でのストレージの歴史をアレコレをまとめてみようと思います。なお、以下swiftと書いたらOpenStack Swiftのことです。流行のプログラミング言語のことではありません。 はるか昔の状況昔は単純にWebDAVを複数台並べ、イッパイになったら更に次の世代のWebDAVを追加する、というような構成で、参照時に画像URLパスに含まれる年月ベースで適切な世代のWebDAVにルーティングしていました。 (参考:画像URLのパスの例) /user_images/20160401/00/shibuya/
インフラのボトルネックを理解する コードはもちろん、リリースしてから安定して動かせるように面倒を見るまでが仕事というのが、弊社の開発スタイルなので、そこで最近学んだことについて、文献や自分の実体験からボトルネックに関する考え方をまとめてみた。 CPUボトルネック CPU使用率に対する基本的な考え CPU使用率が80％から90%をずっと推移している！と聞くと、自分のPCの感覚だと、「やばそう」という感覚に陥りますが、インフラにおいての使用率はそうとも限りません。 CPU使用率高い: うまくリソースを使い切っている CPU使用率低い: オーバースペック ただ、高いCPU使用率にも許容出来る度合いがあったりもするので、そこらへんの判断軸などを踏まえて、まとめてみる。 現実世界の例 CPU使用率が高い状態というのは、実世界に置き換えると、店員がみな忙しく働いているという状態です。利用者からすればオ
AWS 認定 ソリューションアーキテクト – プロフェッショナル(AWS Certified Solutions Architect – Professional)の学習方法 - NRIネットコムBlog
小西秀和です。 この記事は「AWS認定全冠を維持し続ける理由と全取得までの学習方法・資格の難易度まとめ」で説明した学習方法を「AWS 認定 ソリューションアーキテクト – プロフェッショナル(AWS Certified Solutions Architect – Professional)」に特化した形で紹介するものです。 重複する内容については省略していますので、併せて元記事も御覧ください。 また、現在投稿済の各AWS認定に特化した記事へのリンクを以下に掲載しましたので興味のあるAWS認定があれば読んでみてください。 ALL Networking Security Database Analytics ML SAP on AWS Alexa DevOps Developer SysOps SA Pro SA Associate Cloud Practitioner 「AWS 認定 ソリュ
大きく変化した「人とシステム」の関係 企業におけるDX（デジタルトランスフォーメーション）の取り組みが加速する中で、「マイクロサービスアーキテクチャ」（以下、マイクロサービス）の注目度が増している。マイクロサービスは、複数の小さなサービスを組み合わせて一つのシステムを構成するという考え方だ。 マイクロサービスのような「疎結合アーキテクチャ」自体は以前からあるが、「クラウド」「モバイル」といった技術や考え方が普及したことで最近特に注目されている。こう語るのは、Scalarの深津 航氏（CEO、COO＜最高執行責任者＞）だ。 「技術の進歩によって人とシステムの関係が大きく変化した2000年ごろは、社内の情報は社内のシステムに格納され、他社と情報をやりとりするのは主に“人”だった。しかし、2010年ごろになると企業と企業のやりとりも、メールや電話だけでなく、スマートフォンのアプリケーションやWe
訳者、角 征典氏より献本御礼。「7つのデータベース 7つの世界」はそのタイトルの通り、7種類のデータベースソフトウェアについて解説したNoSQLの道標とも言うべき書籍である。7種類のデータベースとして紹介されているのは、PostgreSQL、Riak、HBase、MongoDB、CouchDB、Neo4j、Redisである。本書は非常にそそるタイトルであり、わくわくしながらページをめくった。だが、第2章「PostgreSQL」で期待感は打ち砕かれることになる。 正直なところ、この書籍について書評を書くのはどうしようか迷ってしまった。なぜならば、第2章の説明がかなり間違っているからである。そのため、書評を書こうとするとどうしても辛口にならざるを得なかった。献本して頂いた角氏にその旨を伝えたところ、それでも良いと快く了承して頂いた。本当に辛口になるのでその点は容赦して頂きたい。 何が問題なのか
Railsで秒間1000コミットを捌くにはどうすればいいのか (Kaigi on Railsのフリースペースより) - joker1007’s diary
先日のKaigi on Rails中の雑談として @ima1zumi さんから、RDBに対して秒間1000コミットぐらいで処理が詰まってる場合ってどうするのが良いのか、という質問を受けまして、雑談の中で色々答えてたんですが、せっかくだから記事にまとめておこうと思います。 ちょっとしたKaigi Effectって感じですね。 今回のKaigi on Railsのトークの中では、 数十億のレコードを持つ5年目サービスの設計と障害解決 by KNR - Kaigi on Rails 2023 の話なんかは割と関連がありますね。ユーザーの行動履歴というのは、ユーザー数 * N * タイムスパンで増えていくレコードなので、書き込みとデータ量が爆発しがちです。トランザクションで堅牢に処理しなければいけないケースもそこまで多くないので、RDBだと書き込みに対する処理が過剰なケースが多い。実際のところこの
ふと今更、年初のCROSS 2013の「次世代 web セッション」の動画を見て、うんうん唸ってしまった。プロトコル編の方は知識不足であんまり分からなかったですが、アーキテクチャ編の方はグサグサくるものがあった。「自分の頭でこれからの web を考えてブログに書くまでがこのセッション」という宿題が出ていたので、せっかくなので最近考えてることをつらつらと書いておこうと思った次第。特にまとまりはないですし、戯言です。 これからの Web の話をしよう。 (次世代 Web セッション @ CROSS2013) – Block Rockin’ Codes 前提 僕はコード書いてない＆サーバサイドしか見たことない＆WEB サーバはあんまり見たこと無くて、それより後ろ側ばっかり見てた人なので、ユーザ側とかアプリ開発者がどうなっていくかについて特に尖った意見はありません orz SPDY とかもまだ手を
RDBの限界とNoSQLの登場
事実世界のインターネット人口が増えたのは1990年代からだ。 [引用] http://www.soumu.go.jp/johotsusintokei/whitepaper/ja/h10/html/98wp2-3-1f.html [引用] http://www.soumu.go.jp/johotsusintokei/whitepaper/ja/h29/html/nc144210.html __NoSQL__の登場 1990年に入るとインターネットの利用人口が急激に増加することになる。 この頃からトランザクションに最適化されて設計されたDBでは性能劣化が始まり、システムはデータベースに対しスケール性能を必要とし始める。 多くの開発者は、単一の強力なサーバーでリレーショナル・データベースを実行するのではなく、リレーショナル・データベース管理システム (RDBMS) のパーティショニング (シャー
お久しぶりです、かとじゅん(@j5ik2o)です。テックブログを書くのは何年ぶりか…。 サービスが停止したり応答性が低下すると、お叱りや逆に励ましをいただきますが、エンジニアとして設計レベルからそういった問題に対処するにはどうするか、日々精進しているところですmm。この記事はそういう論点で注目されている「リアクティブ原則」についてまとめてみたいと思います。 それなりのボリュームになってしまったので、時間があるときに読んでいただければと思います。 さて、Linux Foundation内の新たなトップレベルプロジェクトであるReactive Foundationが主催する、Reactive Summit 2020が11月10日にオンラインで開催されたので参加しました。 www.reactivesummit.org 参加されていたスピーカーはLightbendをはじめ、Netflix, Fac
技術書の予習と復習
どうも、株式会社プラハCEO兼エンジニアの松原です 最近若手エンジニアから「技術書や記事からのインプットが遅い、あるいは浅いことに悩んでいる」と相談を受けました。 (自分のインプットの巧拙はひとまず棚に上げて)自分は技術書を読む際は予習と復習を結構するタイプなので、自分なりに工夫していることについて書き残してみようと考えました。超オレオレ理論ですが、悩んでいる方の参考になれば幸いです 本の予習と復習 自分は技術書を読む前後でこんなことをしています: (予習)その本にかける時間を決める (予習)本から学びたいことを書き出す (予習)胡散臭い人に書かれたと考える (復習)仮説を作り、検証する (復習)自分の行動の変化を書き出す (復習)記事を書くか、人に話す 結構面倒だと思いますが、自分にとっては効果的でした 0. その本にかける時間を決める 自分がこれから説明する予習と復習は、めちゃくちゃ時
ソフトウェアアーキテクチャ・ハードパーツ
ソフトウェアアーキテクチャに絶対的な正解は存在しません。むしろ、さまざまな妥協点の中から選択を強いる難題、すなわち「ハードパーツ」が多く存在します。そのため、ソフトウェアアーキテクトには常にトレードオフを見極め、状況に合った選択をすることが求められます。本書は、読者が自身のアーキテクチャ上の難題に対して効果的なトレードオフ分析を行い、より良い決定ができるようにするための書籍です。 本書では、サービスの粒度やデータの所有権、コードの再利用やワークフローの調整、可用性や信頼性の実現といった現代のソフトウェアアーキテクチャの難題と、それに対するさまざまなアプローチやパターンを紹介します。そして意思決定を難しくするトレードオフについて、モノリスを分解しマイクロサービスアーキテクチャに再構築する例を通して詳しく説明します。 『ソフトウェアアーキテクチャの基礎』の著者らによる現代的なトレードオフ分析と
Chris Richardson 氏の Microservices Patterns を読んだ。 Microservices Patterns: With examples in Java 作者: Chris Richardson出版社/メーカー: Manning Publications発売日: 2018/11/19メディア: ペーパーバックこの商品を含むブログを見る マイクロサービスという言葉が出て来て数年経ちます。 私もマイクロサービス的な複数のサービス間でデータのやり取りを頻繁にするようなシステムを構築したことがあります。 その際にデータの整合性は最重要ではなかったのでトランザクション的なものは使いませんでしが、 お金を扱うようなシステムをマイクロサービスにした場合ちゃんとしたトランザクションはどうするのかは気になっていました。 本書にはその疑問に対する現実的な回答が載っています。
サーバーレスシングルページアプリケーション
Webアプリケーションにまつわる様々なリスクとコストを取り除くサーバーレスアーキテクチャをとり入れれば、強力なWebアプリケーションを素早く構築することができます。本書は、実際に動くアプリケーションを作りながら、サーバーレスアーキテクチャの特徴について学びます。 S3でアプリケーションをすばやくデプロイする方法、CognitoでGoogleやFacebookなどのIDプロバイダと接続しユーザーIDを管理する方法、DynamoDBでブラウザから直接ユーザーデータを読み書きし、API GatewayとAWS Lambdaでカスタマイズしたマイクロサービスを構築する方法などについて豊富なサンプルコードを使って解説します。サーバーレスアプローチのシングルページアプリケーションを設計、コーディング、テストして、再び設計にフィードバックする一連の流れを実践的に学べる本書はエンジニア必携の一冊です。 正
Amazon DynamoDBは、RDSのようなインスタンスサイズによる課金モデルではなく、ストレージのデータ使用量とスループットを基にした課金モデルになっている。 インスタンスサイズによる課金モデルでないデータストア系サービスとして、他にはS3、Kinesisなどがある。 これらは、AWSの中でも、フルマネージドサービスと呼ばれる位置づけとなるサービスだ。 フルマネージドサービスは、ElastiCacheのようなそうでないものと比較し、AWSに最適化されていて、サービスとしてよくできていると感じている。 Mackerelの時系列データベースのスタックの一つとして、DynamoDBを採用している。 時系列データベースの開発は、コストとの戦いだったために、それなりにコスト知見が蓄積してきた。(時系列データベースという概念をクラウドの技で再構築する - ゆううきブログ) (※ 以下は、2018
STORESのECサービスを開発している@morihirokです。 STORES ECはRuby on Railsで開発されているWebアプリケーションですが、データベースにはMySQLやPostgreSQLといったリレーショナルデータベースではなく、MongoDBを採用しております。 この記事ではカジュアル面談等で必ず聞かれる「MongoDBって正直どうなの？」といったところを、ストレートにお伝えできればと思います。 なぜMongoDBを採用しているのか そもそもなぜMongoDBを採用しているのか。それは考古学になるのでフィールドワークが必要です。筆者も開発に携わるようになったのは2018年の終わり頃からなので、まずは一緒にSTORES ECの歴史について紐解いていきましょう。 STORES EC（旧STORES.jp）は、heyグループとなるずっと前の2012年、会社名がブラケットだ
集約の境界と整合性の維持の仕方に悩んで2ヶ月ぐらい結論を出せていない話 - kbigwheelのプログラミング・ソフトウェア技術系ブログ
本記事はドメイン駆動設計 Advent Calendar 2018 - Qiitaの3日目の記事です。 2日目は、grimroseさんのぐるぐるDDDで気をつけてることでした。 4日目は、s_edwardさんのMicroservices と DDDです。 Table of Contents Table of Contents 以下の記事を読むにあたり前提となる知識 問題 サービス詳細 ユビキタス言語 重要なビジネスルール モデリング 上の何が問題？ 解決策 解決策1 集約をマージする 解決策2 一時的な整合性の破綻を受け入れ結果整合性を使う 解決策3 アンチパターンではあるが集約間の整合性維持のためトランザクション制御を用いる 解決策4 ユースケースの見直しによる再モデリング まとめ とりあえず今どうやっているか 最終的にどうするべきだと考えているか(2018/12/01時点) ソリューシ
Amazonが社内で開発し、サービスで利用しているDynamoというストレージサービスがあるのだけど、これについての論文が公開されていたので読んだのでまとめてみる。 この論文を書いたメンバーにはAmazonのCTOであるWerner Vogelsや、AWSでDynamoDBやElastiCache、SQS、SNSなどの製品のマネージメントをしているSwami Sivasubramanianらが含まれている。 Dynamoをひとことで表すと分散型でKey Valueストレージで、データの一貫性に関しては結果整合性を保証するサービスだ。なお、AWSで提供されているDynamoDBとは別物なので注意。 原文はこちらから参照できる。今回のポスト中の引用(図や文問わず)はすべてこちらから引用している。 また、既に日本語訳をされている方もいらっしゃるので原文をそのまま日本語でよみたい人はこちらを参照の
Next.js + Vercel + Cloudflare Workers KV + Googleスプレットシートで寄付管理サービスを作った philan.netという寄付の予算を決めて寄付した記録をつけるウェブサービスを作ったので、この記事では技術的な部分の解説をします。 philan.net自体については、次の記事で解説しています。 寄付をするために、寄付の予算と寄付の記録をSpreadSheetベースでつける philan.net というサービスを作った | Web Scratch この記事では、Next.js + Vercel + Cloudflare Workers KV + Googleスプレットシートを使って動いているphilan.netについて解説します。 あと検証中にCloudflare Workersを色々いじったのでそれについても書いていきます。 Idea phila
はじめに 本記事はMartin Fowler氏のBlog記事を日本語訳したものです。 なお、訳は2014/11/09時点のもので、オリジナル記事中のコラムは訳せていません。コラムの訳に関しては、暇や反応を見ながらぼちぼちやろうと思います。 訳に対する指摘・ご意見などありましたらtwitter(@kimito_k)でお願いします。 補足 Martin Fowler氏に連絡をとったところ、主著者はJames Lewisであるとのことでしたのでタイトルを変更しました。(2014/11/13) Microservices "マイクロサービスアーキテクチャ"という専門用語は、ソフトウェアアプリケーションを独立して配置可能なサービスの組み合わせ(suite)として設計する特定の方法を指すものとして、ここ数年で急速に認知されています。このアーキテクチャスタイルに対する正確な定義はありませんが、ビジネス遂
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
RedisサーバのCPU負荷対策パターン - ゆううきブログ
個人的なアプリケーション設計のバイブル3選 - Runner in the High
マイクロサービス設計原則: SOLIDではなくIDEALS
外部パートナーとのAPI連携時に気をつけるポイント - 10X Product Blog
ヤフーの分散オブジェクトストレージ Dragon について
分散システムについて語るときに我々の語ること ― 分散システムにまつわる重要な概念について | POSTD
Facebookが新サービスの基盤にしたのは、MySQLでもCassandraでもなく、HBaseだった
アプリケーションにおけるデータ不整合との戦い - blog.syfm
外部キー制約は何も考えずに適用するとよくない - かとじゅんの技術日誌
『データ指向アプリケーションデザイン』を読んだ - hydrakecat’s blog
大規模な決済システムを構築する際に学んだ分散型アーキテクチャの考え方 – 前編 | POSTD
サーバレスはより安く、より複雑だ | POSTD
TwitterとDiggがNoSQLの「Cassandra」を選ぶ理由
インフラのボトルネックについて知る - ぺい
マイクロサービス化による「DB分割」で開発、運用が難しくなるこれだけの理由
書評：「7つのデータベース 7つの世界」
「これからのWeb(バックエンド)」を自分の頭で考えてみた - As a Futurist...
リアクティブは難しいが役に立つ - Chatwork Creator's Note
Microservices Patterns を読んで(1) - kencharosの日記
DynamoDBのインフラコスト構造と削減策 - ゆううきブログ
STORESってMongoDBを使ってるらしいけど正直どうなの？ - STORES Product Blog
AmazonのDynamoの論文を読んでみた(1/3) - 工場長のブログ
Next.js + Vercel + Cloudflare Workers KV + Googleスプレットシートで寄付管理サービスを作った
James Lewis/Martin Fowlerの"Microservices"日本語訳 - 自由課題