「分散システムデザインパターン」を読んだ
分散システムデザインパターン ―コンテナを使ったスケーラブルなサービスの設計
- 作者: Brendan Burns,松浦隼人
- 出版社/メーカー: オライリージャパン
- 発売日: 2019/04/20
- メディア: 単行本(ソフトカバー)
- この商品を含むブログを見る
目的、モチベーション
- 分散システムの記事等を見たときに、サイドカー等の理解してないキーワードを散見するようになり、理解したかったため。
- コンテナを使ったマイクロサービスを運用しており、理解を深めたかったため。
- Faasなどのクラウドサービスの使い分けを把握したかったため。
全体の感想
シングルノードのときや、マルチノードのときなど幅広く取り扱われており、なんとなく単語レベルでは知ってるパターンの理解を深めることはできた。
インフラ寄りのデザインパターンがほとんどだが、アプリケーションにも関与していて開発しているときにも他の選択肢が増えて視野が広がった気がする。
マルチノードパターンでは、負荷対策などのためのスケール方法が多く記載されていて面白かった。
全体的に解決しようとしてる課題感は掴めたが、現場でSRE的な役割で運用してみないと。
目次
概要
1章 はじめに
分散システムが前提となった時代において、アルゴリズムやオブジェクト指向などと同様にパターン化して公式化することが本書のゴール。
第Ⅰ部 シングルノードパターン
シングルノードパターンを使う理由
- リソースの分離
- 関心の分離・影響範囲の局所化
- デプロイやロールバックを容易にする
2章 サイドカー
1台のマシン上で動く2つのコンテナから構成されるパターン。
ホスト名、ネットワーク、ディスクなど多くを共有する。
3章 アンバサダ
アプリケーションが外部サービスに接続する際に、プロキシとなるコンテナを経由させるコンテナグループを作るパターン。
1. サービスのシャーディングへのアンバサダの利用
Redis等でシャーディングさせてる際に、ノードを増やす度にアプリケーションをデプロイし直す必要がなくなり、ロジックを共通化できてアンバサダコンテナを独立してデプロイすることができる。
2. サービスブローカとしての利用
開発環境や、本番環境などで外部サービスのホストやポートの設定が異なる可能性が高いが、そのロジックをアンバサダコンテナに委譲できる。
3. 新システムの実験的運用やリクエスト分割への利用
バージョンアップなどで新システムを本番環境に導入する際にも、試験的に導入することができる。
例えばアンバサダの設定を変更して、既存のシステムを稼働させつつ、新システムにも同じリクエストを裏側で送って負荷を確認することができる。
4章 アダプタ
コンテナグループ外に対して、外部インターフェイスを提供する際にアダプタコンテナを経由して提供するパターン。
- 監視
- 監視ツール用のインターフェースに変換することで、アプリケーションの責務を分けることができる。
- 監視コンテナを提供する開発者と、アプリケーションの開発者を切り分けることができる。
- ロギング
- 監視と異なり、ログはレベルごとにファイルが異なったり、標準出力してるだけのことがあり、フォーマットがバラバラ。
- アダプタパターンで、モジュール化して再利用して、フォーマットを統一することができる。
第Ⅱ部 マルチノードパターン
6章 シャーディングされたサービス
1. シャーディングされたキャッシュ
シャーディングされてる場合は、一つのノードが死んだ場合に特定のユーザへのレスポンスが遅くなるリスクがあるため、キャッシュのレプリカを用意したほうが高可用になる。
2. シャーディング関数を試してみる
キーの選択
異なる国からリクエストがある場合、言語ごとにキャッシュを切り替える必要があるため、単にIPアドレスを元にハッシュを生成するのは良くない。
コンシステントハッシュ関数
ノードの数を増やすと再シャーディングする必要がある。このとき、シンプルなハッシュ関数だと再シャーディングのコストが高くなる可能性があるが、コンシステントハッシュ関数を使うと効率的に再シャーディングできる。
7章 スキャッタ・ギャザー
バックエンド内で、複数のノードを使って処理を分散させて高速化させるパターン。ただし複数のノードを使うことによるデメリットもある。
- ノードごとのオーバヘッドがあるので、並列性を上げても必ずしも処理速度が上がるとは限らない
- 落ちこぼれ問題(一部のノードでレスポンスが遅くなって全体のレスポンスが遅くなる問題)のため、並列度を上げても処理速度が上がるとは限らない。
- 一つのノードで障害が起こると全体が止まるので、シャーディング毎にレプリカは必須。(バージョンアップを行う際などでノードは必ず止めないといけないタイミングがある。)
9章 オーナーシップの選出
マスタの選出の実装は困難なため、 etcdやApache ZooKeeper、Consulなどのコンセンサスアルゴリズムを利用する。
第Ⅲ部 バッチ処理パターン
Apache Kafkaを使ったPub/Subのパターンや、MapReduceフレームワークでの協調する手法が紹介されていた。
分散システムデザインパターン ―コンテナを使ったスケーラブルなサービスの設計
- 作者: Brendan Burns,松浦隼人
- 出版社/メーカー: オライリージャパン
- 発売日: 2019/04/20
- メディア: 単行本(ソフトカバー)
- この商品を含むブログを見る
「SQL実践入門」を読んだ
SQL実践入門──高速でわかりやすいクエリの書き方 (WEB+DB PRESS plus)
- 作者: ミック
- 出版社/メーカー: 技術評論社
- 発売日: 2015/04/11
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (7件) を見る
目的、モチベーション
- パフォーマンス改善する際に考える材料として、実行計画周りの原理を理解したい
全体の感想
実行計画周りは思ってたより記載されていなかったです。
WINDOW関数などについても言及されており、効率的なSQLを学びたい初心者と中級者の間ぐらいの方にはオススメです。
メモ
効率的なSQLの書き方もたくさん記載されていましたが、あくまでも原理を理解することが今回は目的だったため、割愛してます。
第1章 DBMSのアーキテクチャ──この世にただ飯はあるか
1.1 DBMSのアーキテクチャ概要
- クエリ評価エンジン
- SQLを解釈して実行計画を行う
- バッファマネージャ
- メモリ領域の使い方を管理する
- ディスク容量マネージャ
- 永続的にデータを保存できるように管理し、読み込みや書き込みを制御する
- トランザクションマネージャとロックマネージャ
- リカバリマネージャ
- バックアップやリカバリの制御
1.2 DBMSとバッファ
I/Oアクセスを避けて、いかにメモリ上で処理を行うかが、パフォーマンス改善においてはキーになる。
1.3 DBMSと実行計画
データへのアクセス方法はどう決まるのか
- パーサ(parser)
- オプティマイザ(optimizer)
- インデックス、データの分散や偏り度合い、DBMSの内部パラメータなどの条件から実行計画を作成して、それらのコストを計算して、実行計画を決定する
- カタログマネージャ(catalog manager)
- テーブルやインデックスの統計情報をオプティマイザに提供する
- 遅延が発生すると適切な計画が練れない一方で更新コストも高いため、適切な設定が重要
- プラン評価(plan evaluation)
第3章 SQLにおける条件分岐──文から式へ
3.1 UNIONを使った冗長な表現
UNIONを使うのは、条件分岐という手続き型の発想から脱していないことに原因があることが多い。
SELECT中のCASEで分岐したほうがテーブルのスキャン回数が減るのでパフォーマンスがよい。
3.3 それでもUNIONが必要なのです
CASEによってINDEXスキャンができなくなるときなどは、UNIONを使ったほうがパフォーマンスが良いケースがある。
第6章 結合──結合を制する者はSQLを制す
6.2 結合のアルゴリズムとパフォーマンス
Nested Loops
駆動表とするテーブルを1行ずるループしながら、もう一方の内部表となるテーブルをスキャンして結合条件に合致するものを検索する方法。
アクセスされる行数は、レコード数の積になる。
内部表の結合キーの列にインデックスが存在すると、ループがスキップできるようになりパフォーマンスが改善される。
このとき、内部表が大きい方がスキップされる行数が多くなり、よりパフォーマンスが良くなることが期待できる。
Hash
小さいテーブルからメモリ上でハッシュテーブルをつくり、もう一つの大きいテーブルをスキャンしてハッシュ値が存在するか調べる。
メモリ内に収まらないとTEMP落ちが発生してパフォーマンスが悪化するので注意。
Sort Merge
対象テーブルをソートして、一致する結合キーがあれば結果に含める。
そのため、片方のテーブルのみハッシュテーブルをつくるHashよりもメモリを消費する。
INDEXなどでソートしなくて良い場合には時間とリソースを節約できるため有効だが、基本的には上述の他のアルゴリズムが優先となる。
6.3 結合が遅いなと感じたら
ケース別の最適な結合アルゴリズム
種類 | メリット | デメリット |
---|---|---|
Nested Loops | ||
Hash | ||
Sort Merge |
そもそも実行計画の制御は可能なのか?
MySQLは結合アルゴリズムがNested Loops系しかない。
揺れるよ揺れる,実行計画は揺れるよ
データ量が変更されることで実行計画が変化され、急にパフォーマンスが悪化することがある。
WINDOW関数や非正規化などで、結合をなるべく避ける。
第10章 インデックスを使いこなす──秀才の弱点
10.4 インデックスが使用できない場合どう対処するか
インデックスオンリースキャンによる対処
通常ならテーブルのフルスキャンが発生するようなケースにおいても、選択した列を網羅するINDEXを貼ることで、テーブルスキャンを避けることができる手法。
CREATE INDEX IdAndName ON users (id, name); SELECT id, name from users;
次のアクション
思ったより深ぼれなかったので、SQLパフォーマンス詳解あたりを読んでみようと思います。
SQL実践入門──高速でわかりやすいクエリの書き方 (WEB+DB PRESS plus)
- 作者: ミック
- 出版社/メーカー: 技術評論社
- 発売日: 2015/04/11
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (7件) を見る
Rubyスタイルガイドを読んだ
RoboCopのRubyスタイルガイドからforkされたスタイルガイドを発見しました。
結構前からあるみたいなので、今更感はあります。。
CookpadやMoneyforward、Airbnbなど色んな企業のコーディングスタイルガイドがありますが、
それらと比べて、細かくボリュームもありブレもなくなりそうで良さそうに思いました。
また、宗教戦争が起こりそうなところは、どちらもアリでプロジェクトの中での決めが重要というスタンスなのも良いなと思いました。
いくつか知らないものもあったので、メモ代わりにまとめます。
&&=
ruby-style-guide/README.ja.md at japanese · fortissimo1997/ruby-style-guide · GitHub
# bad if something something = something.downcase end # bad something = something ? something.downcase : nil # ok something = something.downcase if something # good something = something && something.downcase # better something &&= something.downcase
使ったことなかったですが、somethingのnilチェックがスマートに行えます。
Array#reverse_each
ruby-style-guide/README.ja.md at japanese · fortissimo1997/ruby-style-guide · GitHub
# bad array.reverse.each { ... } # good array.reverse_each { ... }
パフォーマンスが良いそうです。
Exceptionのメッセージ
ruby-style-guide/README.ja.md at japanese · fortissimo1997/ruby-style-guide · GitHub
# bad raise SomeException.new('message') # `raise SomeException.new('message'), backtrace`とする書き方が存在しないことに注意しましょう。 # good raise SomeException, 'message' # `raise SomeException, 'message', backtrace`の用法と一貫性があります
Kernel#raise
は下記のように2つの呼び方があり、後者に統一しようとのことのようです。
# [https://docs.ruby-lang.org/ja/2.6.0/method/Kernel/m/raise.html:title]参照 raise(message) -> () raise(error_type, message = nil, backtrace = caller(0)) -> ()
Hash#values_at
ruby-style-guide/README.ja.md at japanese · fortissimo1997/ruby-style-guide · GitHub
# bad email = data['email'] username = data['nickname'] # good email, username = data.values_at('email', 'nickname')
Hashから複数の値を取り出す際には、 values_at
を使った方がスマートに書けます。
Object#__send__
メソッド名の衝突を避けるために、 send
よりも __send__
を使った方がよいというルールです。
例えばEmailクラスで独自のsendメソッドを定義した際に、衝突を回避できます。
(そもそもあまり send
使いたくないですが。)
DBのACID特性
DB周りの理解が浅いなと最近感じ、ACID特性も雰囲気でしか理解してなかったので、自分用にまとめました。
内容を知りたい方は、wikipediaで十分だと思います。
ACID特性とは
一言でいうと、DBに求められるトランザクションの要件のことです。
- A: Atomicity(原子性)
- C: Consistency(一貫性)
- I: Isolation(独立性)
- D: Durability(耐久性)
それぞれ、説明します。
Atomicity(原子性)
トランザクションに含まれるタスクが全て実行されるか、あるいは全く実行されないことを保証する性質です。
例えば、ECサイトでユーザが購入完了する処理と、店舗の在庫が減る処理が片方だけ発生してしまったら、Atomicityを満たしてないです。
Consistency(一貫性)
トランザクション開始時と終了時に制約を満たす性質です。
例えば、決済だけ行われて与信枠が減らなかったり、銀行の残高がマイナスにはなるとConsistencyを満たしてないです。
Isolation(独立性)
トランザクション中に行われる操作の過程が他の操作から隠蔽されるという性質です。
独立性とパフォーマンスはトレードオフの関係にあります。
あまりにも独立性を高めようとすると、一つ処理するトランザクションがあるだけで、他のトランザクションは参照できなくなり、パフォーマンスが低下します。
そのため例えば、MySQLではトランザクションの分離レベルが設定できます。
MySQL :: MySQL 5.6 リファレンスマニュアル :: MySQL 用語集
Durability(永続性)
トランザクションが完了したら、障害が発生したとしても結果は失われないという性質です。
ディスクに保存されておらずメモリ上で残ってるだけの状態で、ハードウェアに障害が発生した場合に、データが飛んでしまうと永続性がないです。
「チャイナ・イノベーション データを制する者は世界を制する」を読んだ
- 作者: 李智慧
- 出版社/メーカー: 日経BP社
- 発売日: 2018/09/28
- メディア: 単行本
- この商品を含むブログを見る
目的、モチベーション
全体の感想
アリババやWeChatの歴史を中心に俯瞰できてよかった。
海外規制してるから中国は国内の大きなサービスが育ってるという印象を持っていたが、昼夜問わずハードに働いたり、学術研究に投資して優秀な人材を確保したりするなど、成功すべくして成功してるんだなと思った。
中国政府は規制に対して厳しい印象を持っていたが、緩やかにその事業が世間にどのような影響を与えるか様子を見て、事業者と連携しながら規制しているのも印象的だった。
キャッシュレスを制するには、オンラインと連動してクーポンを配布したり、ミニプログラムを提供するなどして利便性を確保して、オフラインとの境界を抑えるのが重要なのかなと思った。
そこで得たデータを元に信用情報を構築して、新たなサービスも提供できる。
日本でのキャッシュレスキャンペーンは少し不毛だなと思っていたが、それで一大ブームになって定着するという側面もあるので、一面的には判断できないとも思った。
中国のITの現状や歴史をあまり詳しくなくて、アリババやWeChatを中心に中国のFintech事情を知りたい人にはオススメです。
目次
- 目的、モチベーション
- 全体の感想
- 目次
- 概要のメモ
概要のメモ
序章 米中貿易戦争とチャイナ・イノベーション
第1章 習近平国家主席とデジタル強国路線
国策として推し進めてる。 アメリカから制裁を受けたり、若者の就職先がないことの解決策の一つとして、国が起業やイノベーションを支援する。 その中で中小企業が飛躍できるように大手企業がプラットホームとして、機能などを提供することを要請。 その流れで、アリババやテンセントの決済がプラットホームとなり様々なサービスが生まれていくことになる。 技術の中ではAIで世界一になれるように、教育や、優秀な人材が集まる支援を積極的に行われた。
第2章 なぜ中国でイノベーションが爆発的に生まれているのか?
モバイル決済がイノベーションの起点
3G回線のインフラが整ったことや、シャオミやファーウェイなどの格安スマホによって、爆発的にモバイルのユーザ数が増えた。
また、国土が広くATMが日本と比べて便利なレベルでATMがなく、クレジットカードの普及も進んでいない。
そのやめ、オンラインでの決済ができないユーザが多かったが、アリペイがその解決になった。
モバイルの移行に伴い、アリペイウォレットを提供開始。急成長の要因は2つある。
1つ目は、6%を超える利息を受け取れるMMF(マネー・マーケット・ファンド)の発売(銀行の普通金利は0.35%)によって収益を生む財布として人気を得たこと。
2つ目は、独身の日のキャンペーンで、好調だったアリババのネットショッピングのユーザをモバイルへの誘導が功を奏したこと。
これらのシェアリングエコノミーは、利用者の信用情報の蓄積にも繋がる。
芝麻信用では、決済履歴や資産運用履歴、行動特性などの情報を分析し、ゴマスコアとして信用情報を数値化している。
欧米ではプライバシーが重視されてしばしば問題になるが、中国では利便性をもたらしてくれるなら気にしないぐらいの温度感で社会的にも受け入れられている。
アリペイのおかげで、サービスに必要な本人認証と決済をプラットフォームに任せることで、オフラインの様々なシェアリングエコノミーも普及している。
オフラインで使えるサービスを提供し、モバイル決済を普及させると共に、利用データや信用情報を蓄積させ、そのビッグデータから新しいサービスを提供していく。
データ蓄積によって個人の信用を点数化
アント・フィナンシャルの手掛けるゴマ信用は、取引履歴や支払履歴、行動特性などのデータを分析し、個人の信用力をゴマスコアとして数値化。
ゴマスコアに応じて少額融資を行い、TmallやTaobao等で買い物する際にも使える。
従来の中国人民銀行の信用情報サービスでは、銀行のデータから構築したために半分以上の国民は基礎情報しかないのに対して、ネット企業は様々な情報からスコアリングが行える。
個人情報が企業に利用される形になるが、利用者の殆どは、様々な利便性をもたらしてくれるならあまり気にしないという温度感。
第3章 阿里巴巴(アリババ)集団と騰訊控股(テンセント)――中国版巨大プラットフォーマーの誕生
なぜアリババが成功したのか?
信用情報が未整備で、クレジットカードの保有率の低い中国では決済のコンバージョンが悪く、eBayなどの欧米のスタイルがなじまなかった。
それに対して、アリババはエスクローサービスを中国で最初に導入した。
ジャック・マーの「問題が起きれば、僕が刑務所に行く」という強い決心で開発が急ピッチで進んだ。
いざリリースしても、非銀行であるアリババを不安に思うユーザが多く、不安を払拭するために全額補償のキャンペーンを行った。
さらに、手数料を無料化してeBayと差別化を図った。
独身の日のセールの負荷に耐えられるように、Ocean BaseやAliyunを自社で開発し、分散型アーキテクチャに移行して対応した。
これらの技術力を活かし、他社にもアリババクラウドを提供する。
決済手段から生活サービスのプラットフォームへ
ダブル11のオフライン版であるダブル12では、スーパーやレストランなどで半額のキャッシュバックキャンペーンを行い、デジタルに疎い50,60代にリーチすることができた。
決済件数が増えるだけでなく、加盟店はレジ精算時間も大幅に短縮され業務改善にもつながった。
海外展開は、ローカルの企業に出資などして提携を結んで進めた。
微信(ウィーチャット)発展史
単なるメッセンジャーから、SNS的な機能を付け加えていき、国内では独占状態になった。
「テンセントが進出する事業には手を出さない」という暗黙のルールができるほど無双状態になる一方で、独占状態に批判が集まるように。
そこでオープン化戦略を取ることにし、サービス提供者向けにユーザとつなげるツールを提供。
- 購買アカウント
- 情報発信
- サービスアカウント
- 会員管理、販促
- 企業アカウント
- 内部管理の効率化、関連企業や顧客とのコミュニケーションの円滑化を支援するSaas
2017年1月には、wechat内で完結しDLも不要なミニプログラムをリリース。
お年玉をwechatで送れる機能では、ゲーム性を取り込み、テレビの人気番組と連動したキャンペーンを行い、ユーザを引き込んだ。
大晦日の0〜19時の間で、2000万人が4億回のお年玉のやり取りを行った。
第4章 2強を追う先端技術企業
滴滴出行(DiDi)――本家も飲み込む生命力
滴滴出行は最初は投資家やユーザもおらず、運転手の10数名しかいない状態でスタート。
SNSのクチコミで徐々にユーザ数が増え、優秀なエンジニアを雇って開発を内製にすると、マッチングの効率化等の改善を行い、事業が成長していった。
wechatで決済できるなどして連携を図っていく一方で、アリババが出資する快的打车も順調にユーザ数を伸ばす。
キャンペーン合戦となりお互い大きな赤字を掘り、最終的には合併にいたった。
UBERは中国に進出し、運転手に高い奨励金を出して繋ぎ止めを図る。
真っ向から勝負となったが、CS対応は電話が一般的な中国でメールで対応するなどローカライズできず、細やかな改善を重ねた滴滴出行がシェアを守った。
泥沼の赤字の戦いは、投資家主導で休戦することになり、UBERが滴滴出行の5.89%の株式を取得することで幕を閉じた。
フィンテック企業やAIスタートアップの紹介
- 世界最先端のフィンテック企業
- 衆安保険-―従来の発想に捉われない商品開発で急成長
- 微衆銀行(WeBank、ウィーバンク)――中国初の民営銀行
- 京東金融(JDファイナンス)――アント・フィナンシャルの後を追う
- 急成長するAIスタートアップ企業
第5章 急速に進むデジタル化の負の側面
頻発する悪質ネット詐欺
資金を投資家から集めながらも、私的に利用されて資金が回収できなくなった事例等が紹介されていた。
ICOでも詐欺的な問題が発生し、規制による取締が行われた。
羊毛党vsネット企業――テクノロジーを悪用した詐欺集団
セール商品を大量に転売されたり、プロモーションのキャンペーンを不正に受け取るために、架空の取引を発生させるなどの事例が紹介されていた。 犯罪にもAIが応用されて、ツールが販売するなどして不正収入を受け取られてる。
第6章 中国型イノベーションの本質と先端企業との付き合い方――ユニクロ、メルカリの事例
ユニクロの中国戦略
wechatの公式アカウントを広めるために、シェアすればするほど当選確率の上がるキャンペーンを行った。
独身の日は売上が立つが、流通が追いつかない。 そのため独身の日だけ、オンラインとオフラインでセール価格を統一して、オフラインの店舗で受け取れるようにした。
- 作者: 李智慧
- 出版社/メーカー: 日経BP社
- 発売日: 2018/09/28
- メディア: 単行本
- この商品を含むブログを見る