set setting reset

脂肪と糖にはたらくやつ

Mac の pbcopy と同じことを Windows Subsystem For Linux (ubuntu) でもやりたい

はじめに

最近ギョームマシンをMacからWindowsに変えました。
Windows Server Container を使うかもしれないし、WSL がよくなっているという噂を聞いたので、もしかして Windows を使わない理由がないのではと考えたからです。
ただ、細かいところで Mac での慣れが通用しないことがあり、表題の件もその例の一つです。

pbcopy とは

pbcopy は標準出力をパイプで食わせるとクリップボードにコピーできる便利機能です

ubuntu on WSL では

ぐぐるxsel なるものを使うとよいとあったので試してみます。

$ sudo apt-get install xsel

インストールしたら cat hoge.txt | xsel --clipboard --input のように使うとのことでしたが、以下のエラーとなりました。

xsel: Can't open display: (null)
: Inappropriate ioctl for device

なんだか難しそうなエラーなので他の方法がないか調べてみます。

clip.exe

すると Stackover Flow にたどり着きました。

stackoverflow.com

WSL では Windows 上の exe をシームレスに扱えますので、Windows 標準の clip.exe で事足りそうです。

$ cat hoge.txt | clip.exe

あとはエイリアスを作りたければご自由にという感じですね。
この件はしばらくこれで乗り切れそうです。

宛先ごとに並列でpingする

というものをpythonで作りました。

github.com

pacemakerping RA というものを使い、スプリットブレイン対策のためにNW監視をしているのですが、
宛先ごとにシーケンシャルに ping を撃つという仕様であることから、対象に増減があると timeout などの調整がしんどいというマイナーな事情がありまして。
それを置き換えたいという目的です。

所感としては concurrent.future が便利でした。
また、 Subprocess にも run というメソッドが追加されていて、とても使いやすかったです。

SHIROBAKOとチームビルディングについて

この記事はSHIROBAKOアドベントカレンダーの12日目です。

adventar.org

SHIROBAKOといえば最高なわけですが、なぜ最高なのかは人それぞれでしょう。
ただ、モノづくりの現場を描ききった本作に何かしらのシンパシーを感じている方は多いのではないでしょうか。
ぼくもへなちょこDTMerであり、へっぽこエンジニアだったりするので、感じるものがあります。

現代においては(本質をついているかどうかはともかく)アジャイル開発はある種スタンダードになり、
DevOpsやSREといった発展した文脈も生まれてきている中、それらが原因というわけではないにしても現場に唐突な変化が起きることは少なくありません。

人は基本的に集中を削がれるのを嫌う生き物ですので、場当たり的な変更が繰り返されると疲弊してしまいます。 でもモノづくりは好きだし、携わっていて思い入れも強いプロダクトは成功してほしい、そんなモチベーションで課題やタスクと対峙するという日々を送ったり送らなかったりしています。

そんな感じで心が荒れ気味のとき、SHIROBAKO 2話 「あるぴんはいます!」はキます。

f:id:rriifftt:20181211220444p:plain
あの。。つまり原画から全部新作ということですか???

冒頭から立ち込める暗雲、そして訪れるカオス。やばそうなイキフン。
監督と円さんの口論を経て、なべPに無茶振りされたみゃーもりは緊急会議を開くことにします。

f:id:rriifftt:20181211223331p:plain
今回の作画を直すとして、作業に入る前にもっかいあるぴんやえくそだすっ!のキャラについて、みんなに確認しておくのはどうでしょう?大切なことだと思うんです。

昨今では心理的安全性といった言葉をよく聞くようになりました。チームのパフォーマンスを最大化するためのフレームと捉えていますが、Googleでは 効果的なチームを可能とする条件は何か というリサーチを行ったそうで、この re:Work という記事はちょっとした話題になりました。

rework.withgoogle.com

個人的には、そんなんなくてもどうにかするのがプロでしょっていうのと、やっぱ人間だし必要だよねそういうのっていうのが半々だった時期があるのですが、ないよりはあった方がいいに決まってるじゃんと言われると、まぁ、ぐうの音も出なかったわけです。

モヤッてるときにモヤッたまま進むとモヤッたモノができます。
モヤッたモノに関わった人たちは、少なからずモヤモヤを抱えなければなりません。できればどうにかしたいものです。

どうにかするには、答えは状況によりけりでしょうが、物語の中では対話をすることになります。

f:id:rriifftt:20181211223956p:plain
演出プランを全面的に見直すそうです!

立ち話はコスパがよい と聞いたことがありますが、たしかに話すだけで済むなら簡単です。
対話によって 自分はその場に参加している という当事者意識も働くでしょう。質のよい時間であった方がよいという合理的な判断から、ネガティブであってもポジティブであっても建設的な議論をすることを心がけるでしょう。
そして、よい議論を行うにあたっては、そもそも心理的安全性が前提として必要だったりもします。また、共感も重要な要素となることがあります。

f:id:rriifftt:20181211231159p:plain
うんうん!わかるわかるー!

という共感からの

f:id:rriifftt:20181211231722p:plain
良くも悪くも脇が甘いんですよねー

この山田さんの表情なんかは非常によい例ではないでしょうか。

f:id:rriifftt:20181211232219p:plain
さっきまでこうだった人が
f:id:rriifftt:20181211231722p:plain
こうですからね(しつこい)

そんなこんなで監督の思いがみんなに伝わり、

f:id:rriifftt:20181211232749p:plain

なんやかんやで、あるぴんはここにいます!になるわけです。

re:Workの話に戻ると、チームの課題として以下のことが挙げられています。

従業員はほとんどの仕事をチームの一員として行います。しかし、チームの対人関係に問題が生じたり、メンバーのスキルが適切でなかったり、あるいはチームとしての目標が明確でなかったりすると、生産性の低下やメンバー間の摩擦が生まれるといった問題が生じかねません。

このような課題に対するある種の回答が、このお話には内包されていると思うのです。
人と人がわかり合うニュータイプ的な感覚を共有することと、攻殻機動隊的なスタンドプレーによるチームワークというような、個人的に理想的なチーム。
いいなぁと思うわけです。いいなぁ。

まぁ、そもそも監督ちゃんとしろよという意見ももっともですが、口下手な監督もいますからね。仕方ないですね。
ギャップがあることが問題であるなら埋めた方がいいでしょうね。

見返せば見返すほど発見があるSHIROBAKOですが、今回はこんなところです。

最後に、心理的安全性という観点では監督がスタジオでこんなことも言っていますね。

f:id:rriifftt:20181211233840p:plain
あたしここにいていいのかな?いてよーし!みたいな?

武蔵野アニメーションGoogleかなんかなのかな。

こちらからは以上です。ありがとうございました。

pgpool インストール時に configure: error: header file <libmemcached/memcached.h> is required for memcached support

背景

pgpool-4.0.1 を検証していたら pgpool-4.0.2 が出たのでインストールしてみたところ表題のエラーとなりました。

エラー発生時のインストール手順

pgpoolのインストールはソースから行いますが、インメモリクエリキャッシュを使いたいのでlibmemcachedをインストールします。

# yum install libmemcached

以下の手順で configure してみると WARNING がでます。

# cd /usr/local/src
# curl -L 'http://www.pgpool.net/download.php?f=pgpool-II-4.0.2.tar.gz' -o pgpool-II-4.0.2.tar.gz
# tar xzf pgpool-II-4.0.2.tar.gz
# cd pgpool-II-4.0.2
# ./configure --with-pgsql=/usr/pgsql-9.6 --with-openssl --with-libmemcached=/usr/lib64/libmemcached.so.11

~略~
configure: WARNING: unrecognized options: --with-libmemcached 

--with-libmemcached オプションは非サポートとなり、 --with-memcached となったようです。
なお、ビルドそのものは可能でした。

オプションを変更して再チャレンジしてみると前述のエラーとなりました。

# ./configure --with-pgsql=/usr/pgsql-9.6 --with-openssl --with-libmemcached=/usr/lib64/libmemcached.so.11

~略~

checking libmemcached/memcached.h usability... no
checking libmemcached/memcached.h presence... yes
configure: WARNING: libmemcached/memcached.h: present but cannot be compiled
configure: WARNING: libmemcached/memcached.h:     check for missing prerequisite headers?
configure: WARNING: libmemcached/memcached.h: see the Autoconf documentation
configure: WARNING: libmemcached/memcached.h:     section "Present But Cannot Be Compiled"
configure: WARNING: libmemcached/memcached.h: proceeding with the compiler's result
configure: WARNING:     ## ---------------------------------------- ##
configure: WARNING:     ## Report this to pgpool-hackers@pgpool.net ##
configure: WARNING:     ## ---------------------------------------- ##
checking for libmemcached/memcached.h... no
configure: error: header file <libmemcached/memcached.h> is required for memcached support

why?

メッセージの通り libmemcached/memcached.h が存在しないためのようでした。
yum でインストールしたからでしょうか。バイナリのみがサーバー上に存在しています。

# updatedb && locate libmemcached
/usr/lib64/libmemcached.so.11
/usr/lib64/libmemcached.so.11.0.0
/usr/lib64/libmemcachedprotocol.so.0
/usr/lib64/libmemcachedprotocol.so.0.0.0
/usr/lib64/libmemcachedutil.so.2
/usr/lib64/libmemcachedutil.so.2.0.0
/usr/share/doc/libmemcached-1.0.16
/usr/share/doc/libmemcached-1.0.16/AUTHORS
/usr/share/doc/libmemcached-1.0.16/COPYING
/usr/share/doc/libmemcached-1.0.16/ChangeLog
/usr/share/doc/libmemcached-1.0.16/README
/usr/share/doc/libmemcached-1.0.16/THANKS
/usr/share/doc/libmemcached-1.0.16/TODO

libmemcached をソースでインストールしてみる

以下の手順で libmemcached をソースからインストールしてみます。

# curl -L https://launchpad.net/libmemcached/1.0/1.0.18/+download/libmemcached-1.0.18.tar.gz -o libmemcached-1.0.18.tar.gz
# tar xzf libmemcached-1.0.18.tar.gz
# cd libmemcached-1.0.18
# ./configure
# make
# make install

すると、 libmemcached は /usr/local/include/libmemcached にインストールされます。

# updatedb && locate memcached.h
/usr/local/include/libmemcached/memcached.h
~略~

再度 pgpool をビルド

先程のエラーメッセージでは configure: error: header file <libmemcached/memcached.h> ということでしたが、
まさかヘッダーファイルのみをオプションに指定するわけではないだろうということで、ディレクトリを指定してみるとビルドが通りました!

# ./configure --with-pgsql=/usr/pgsql-9.6 --with-openssl --with-memcached=/usr/local/include/libmemcached
# make && make install

こういうものなんですかね。
とりあえずこれで進めてみます。

翻訳してみた AWS re:Invent 2018: Building SRE from Scratch at Coinbase during Hypergrowth

Sansan Advent Calander 2018 の4日目の記事です。

adventar.org

先日参加させてもらったre:Invent、超たのしかったっす。
その中で面白かったCoinbase社、及びDataDog社によるSREの取り組みについてのセッションをご紹介したいと思います。

www.youtube.com

拙い翻訳で心苦しい限りですが、何かしらの気付きになれば幸いです。

本人より許可いただいています。 Thank You so much.

SREとは何か

新しいものだから定義は変化し続ける。
その中で多くの誤解があるようだ。

これはSRE?

終わりのない火事場?なりやまないオンコール?トイルへの対応?
これらはSREの仕事ではない。

これらは症状であり、この病気に苦しんでいるのなら治癒する必要がある。
それを治癒するのがSREの仕事である。

Devopsとは?

SREは、すべてではないにしても、devopsのオペレーション、及び文化上の要素を満たすことができる

SRE本にもあるように、SREはdevopsの実装の一つであると言われている。
もし既にdevopsをやっているなら、SREはすぐにフィットするだろう。

Key SRE insight #1

計測し、人、組織、システムを改善する

SREはシステムだけを見るのではなく、インシデント発生時のプロセス、あるいはそれから何を学ぶか、組織のプロセスを改善できるか等の側面からアプローチする必要がある。
そのために常に、全てを計測しなければならない。

Key SRE insight #2

受動的ではなく自発的に。トイルを見つけ出し、それを排除する

自宅に火事が起こったら燃え尽きるまで見ているなんてことはせず、消防士を呼ぶだろう。
あるいは、実際に火事が起こるのは嫌なので発生を検知するために火災報知器を設置するなどの積極的な行動をするだろう。
これは問題が大きくなる前に排除するにあたって有効な手段だ。

受動的ではなく自発的に。これはとてもとても重要だ。

トイルとは?
トイルとはスケールしない手動のオペレーションであり、組織とともにどこまでも成長することがある。
成長するトイルを見逃していては組織の成長は阻害されるだろう。
SREはこの問題に対処する必要がある。

Key SRE insight #3

組織的なフィードバック

例えばデータベースのパフォーマンスがよくない状況においてはデプロイを止めた方がいい時がある。
これは適切なフィードバックがあるからできることであり、システムの信頼性を維持するには必要かつ重要なことだから、コミュニケーションには重点を置くべきである。
トップダウンボトムアップの双方で意識されるべきことだ。

Set Early Expectations

SREは新しい概念なので、新しい用語が多くある。
即時的な結果を求めず、ある程度の時間をかけながら始めるのがいいだろう。
でも何から始めればいいか?
Coinbase社では以下の戦略を取ることにした。

Service Level Indicators

何をどう改善すればよいか?何もなければよくわからない。
計測し、現状を理解し、サービスレベルの指標を設定することにした。

作業を進めるときなどには優先度を設定するが、それはどのように設定されるのか、客観的な指標を持つべきである。
その指標にはFour Golden Signalsというフレームが非常に役立つ。
我々はこれらをSLIのコアメトリクスとして採用することにした。

コアメトリクス

データは大量にあるかもしれないが、そのどれもが有用とは限らない。
ビジネスをゴールに向かわせるために本当に大切なメトリクスは何か、それを見極める必要がある。

Four Golden Signals

Four Golden Signalsとは以下のメトリクスである。

  • Latency
  • Traffic
  • Errors
  • Saturation

これらはどんなサービスにも適用できる普遍的な指標であると言える。
また、これは後述するが、人、チーム、組織に置いても適用することができる。

Latency

レイテンシーとはクライアントがWebサーバーからレスポンスを受け取るのにどれくらい時間がかかるのかを示すものであり、顧客の経験に直接的な影響がある。
なぜ遅いのか、それはあなたが計測する方法に依存するので難しい問題である。

ロードバランサーで計測するか、クライアント側でラウンドトリップを計測するか、あるいはサーバー側で計測するか、様々なオプションがあるだろう。
実用的な値を計測するにも複雑になりうる。まぁ、これら3つ全てが取れるならかなりいいよね。

Traffic

トラフィックとは作業量、または試行回数を意味する。
トラフィックはビジネスの価値、規模に大きく関係するが、大量のトラフィックに見舞われた時にシステムのどこかで落ちてしまうことがあるだろう。
なので、しきい値を設定する必要がある。

Errors

成功したリクエストと失敗したリクエストの比率をターゲットとして設定するのは簡単だし、効果的だろう。
例えば昨日はサイバーマンデーで、新たな導線を敷き、大量の消費行動が行われたとして、エラーレートが50%であれば使い物にならなず、0.1%であればそれは良い数字であると言えるだろう。

複雑なシステムではエラーが発生するのは当然起こりうることであるから、ゴールはエラーを排除することではなく、エラーをどこまで許容するかを明確にすることである。
また、このエラーレートを低く維持することをビジネス上の重要な目標とすることが望ましい。

Saturation

TrafficとSaturationは何が違うのか?
Trafficは試行の総量であるのに対し、Saturationは使用可能な総量である。
たとえばWebサーバーのメモリ使用量、DBのディスクスペースといったものだ。
これはソフトウェアそのものではないことから、いつでもどこでも起こりうることなので、指標としてこれまた重要なものであると言える。
ただし、Saturationが発生することはトリッキーな事態であるとも言える。

Humans and the Four Golden Signals

Four Golden Signalsは人やチーム、組織にも適用することができる。

Latencyは、人々がブロッカーを待っている時間に例えることができる。
依存関係のあるタスクを待つなどといった状況のことだ。

Trafficはそれより劇的で、スタックしているチケットの数として見ることができる。

Errorについては、人間は誰しも多かれ少なかれミスをする。
何らかの仕組みが必要となることがあるだろう。

Saturationを人という観点から見たときには燃え尽き症候群のようなものがイメージしやすいのではないだろうか。
燃え尽き症候群は大企業にとって大きな課題である。

Start, Then iterate

you can't finish something that you don't start

これらの課題に対するためには、まずはどこからか始めなければならない。
始めるにあたっては完璧である必要はないし、完璧であることはできない。
シンプルに!

繰り返し、フィードバックを与え、得ることが重要だ。ここに魔法はない。

Spreadsheets are simple, right?

さて、システム、ならびに組織にSLIを適用するにはどうすればいいだろうか。
適切なツールを使うことはやはり効果的だろう。

スプレッドシートはいいぞ(突然の金言)
見やすいし、シンプルだし、シェアしやすく、アクセス性もよい。
簡単にコラボレーションできるしオススメ。

サービスごとのFour Golden Signalをカラムに追加することから初めてはどうだろう。
追加サービスがあるのなら行を追加すればいいし、簡単だ。

SLIs: Defining "done"

システムやサービスにSLIを規定し、スプレッドシートを作成し、運用を開始したとする。
そしてFour Golden Signalsの内のいずれかがSLIに抵触したために作業をしたとして、完了したことを我々はどうやって知ればいいだろうか?

そのためには完了した状態を定義しておくとよいだろう。

まず第一に監視システムや、JIRAのチケットに完了したことを報告する。
次にどのようにして完了させたかを説明するためのドキュメンテーションを行う。

これは常に明確なドキュメントでなくてもよい。
なぜならどのようにこの指標を使用しているか、なぜ重要であるのか、誰が気にするべきなのかは必ずしも明白とは言えないからだ。
(結構ゆるめだなーという印象)

ダッシュボードはあなたの友達だが、注意すべきだ。
ダッシュボードには多くの情報があるはずだが、常に十分な情報があるわけではないので、翻弄されないようにした方がよい。

すでにSLI抵触に関するイテレーションが適切に回っている?それなら問題ない。

start somewhere, this is good place to start.

付け加えておくと、大きな障害を避けるためには予測をすることもとても重要だ。

Specification Documentation

SLIの抵触はCriticalな事態だ。
だからこそ、なぜその指標が重要なのかをドキュメントにしておくとよいだろう。

例えば、元々はELBでレイテンシーを計測していたが、やはりモバイルアプリのクライアント側で計測することが最適であるとして、メトリクスを変更したとしよう。
このような時にドキュメントが重要になってくる。
なぜこの指標が重要であるのか、また、それについての将来のロードマップがどのようなものであるのかを話すことができるからである。

SLIの文化を構築するには仕様文書を作成することに非常に大きな価値がある。
やみくもドキュメント化するのではなく、組織の求めるものは何かを念頭に置き、重要なメトリクスをドキュメント化するとよいだろう。

First SLIs, then promises

あなたは顧客のために何を約束しますか?
また、他のチームが約束していることはあなたに依存しますか?
途方もないことかもしれないが、それについて考える必要があるだろう。

でも恐れることはない。良いPM、良いSREはビジネスの価値を知り、問題解決の能力があり、あなたの問いかけに回答してくれるだろう。
その下地を作るためにも計測し、改善し続けるしかない。

なぜこのようなことをしなければならないのか。
数千のメトリクス、重なる工数、難解な問題は山積みだ。

でも答えは一つ、それは約束を守るためだ。

突然の書籍紹介

Thinking in Promises.
http://shop.oreilly.com/product/0636920036289.do (とてもいい本らしい)

Concerning Promises

promiseには2つのコンポーネントがあり、この場合は人間と機械である。
promiseは人間から機械へ、人間から人間へ、機械から機械へと設定することができる。

それらは常に対等の責任を負う必要はないが、それらの組み合わせの意味を考えることが重要である。
この組み合わせは機能を横断したチーム同士が協力しあっている状態であることが望ましく、より単純な帰結をもたらすだろう。

それは例えばAPIであったり、メッセージキューであったりするかもしれない。

Promises Example

promiseは平易に、明確に明文化すると効果的だ。
それを満たすか、満たさないかがひと目でわかるように。

promiseはSLIに組み込まれることもある。
(SRE本で言うところのSLOがpromiseであるようだ)

例として以下のようなものである。

  • response within 50ms
  • error rate will be > 1%
  • on call 15min

Promise Enumration

各チームはpromiseを列挙したら公式化し、維持なければならない。
また、その機能が果たすべきpromiseを理解していなければならない。

When Promises are Broken...

promiseが破られることは回避できない。
だからこそ、その時に何をすべきか規定しておかなければならない。

インシデントが発生したらどうする?
インシデント発生時のフィードバック方法は規定されている?
継続的なフィードバックは非常に重要である。

Post-Mortems

ポストモーテムには色々とあるが、重要なことは正しい計測、結果の分析、対処である。
そのためには計測した結果を正しく理解し、活用できなければならない。
これができなければポストモーテムはうまく回らないだろう。

Interpreting Incidents

ステークホルダーも交えて共通言語を決定しておくとスムーズに事が運ぶ。
英語なのかフランス語なのか、公式言語は決めておいた方がよい。そのための訓練も重要だ。様々な言語が飛び交う現場は混乱を招くだろう。

また、言うまでもなく発生したインシデントは広く共有すべき。

Mesuring Incident Response

インシデントを定量的、定性的に計測するとよいだろう。
定量的にはインシデントを検知した時間、着手開始時間、リカバリーするまでの時間など。
定性的にはコミュニケーションは適切だったかなど。
これらの継続的なフィードバックは改善に向けて非常に重要である。

富士そば 巣鴨店

富士そばアドベントカレンダー、今年も発見してしまったので2日目に参加させていただきます。

adventar.org

富士そばしゅき度としては、先日まで会社のお金でAWS re:Inventに参加しており、1週間ほどラスベガスにいたのですが、
滞在残り2日くらいになったころから、さて日本に帰ったら何を食べようかとか考えるまでもなく、まぁ富士そばしかないなと思う程度のものです。

というわけで、今回は巣鴨店です。
巣鴨店といえばクッソみたいに泥酔したときに流れ着くことが多く、信頼の終着点として心を置かせていただいている店舗です。

成田からそそくさと巣鴨店に向かうと、そこには衝撃の光景が。

f:id:rriifftt:20181201201153j:plain f:id:rriifftt:20181201201224j:plain

まじかよ。かなしい。
でも駅の反対側に新店舗ができているようでした。

f:id:rriifftt:20181201204329j:plain

とりあえずよかった。そしてカレーカツ丼がある店舗なのもポイント高いですね。
新店舗だからかテーブル席があり、演歌ぐあいも完璧です。

今回注文したのは渋谷店でよく食している紅生姜ちくわ天そばにしました。
f:id:rriifftt:20181201202220j:plain この邪悪さすら感じるビジュアル、最高ですね。
前日の夜から20時間以上なにも食べずに富士そばを狙ってきたこともあり、秒で完食です。

秒だったので正直味とかよくわからなかったですが、この新巣鴨店はカエシが強くなく、やさしい系の出汁だったなーという印象です。
こういうのもいいけど、次は真っ黒なところに行こう、そんな風に思いました。

はい。 こちらからは以上です。

20181121. Aurora Architecture Night メモ

表題のイベントに参加してきました。 ハイパー殴り書きです。Auroraすげーくらいの感想しかなかった。

postgresql compatibility

  • pg10 に対応
  • RDS Snapshot -> Aurora Migration
  • 様々なExtensionをサポート
    • GIS
    • pgceypto
    • plpgsql
    • pg_hint_plan
    • postgres_fdw
    • dblink -> 関数として実装されている
      • Aurora -> Redshift
        • Redshiftに計算、集計をオフロードするなど
    • 相変わらず pg_bigm と textsearch_ja がない

Concurrency

  • remove log buffer

    • WAL Buffer -> buffer がいっぱいになるとワーカーが待たされる
      • これがオーバーヘッドになると判断したらしいとか
    • ワーカーが直接ストレージにアクセスする
    • Durability tracking
  • Checkpoint

    • CheckPointがない
      • Bufferがないからストレージ直接書き込み
  • Redoしない

    • ?

Vacuum

  • XID周回問題
    • CloudWatchにメトリクスがある
  • freeze map
    • 9.6から
    • VACUUMすべきタプルを管理
    • Aurora には Filesystem がない
      • ?
    • Intelligent VACUUM Prefech
      • VACUUMが86%速い

Scalability

  • 各AZに2つずつ、系6つのデーターのコピーを保持
  • master / repllica が同じストレージを参照している
  • Write のパフォーマンスが一定
  • クラッシュリカバリをストレージ側で行う

Auroraの新機能

  • Backtrack

    • 全てのログレコードを保持
      • LSN(Logical Sequence Number)が付与されている
    • ストレージ側が見せるブロック(LSN?)をヘッドノードに伝えることで制御している
    • 最大3日
    • 専用の領域を必要とするのでストレージ課金対象
    • 常に一貫性のある時間にBacktrackを行う
      • Votingが確定していることかな
  • Aurora Serverless

    • 完全マネージドな感じ
    • 設定とかできない
    • 軽いロードのDB向け
    • proxy endpoint -> Request Router -> NLB -> DB
    • ダウンタイムなしの自動スケールアウト
    • 0からスケール
      • 使わなければインスタンスだけ削除するという設定が可能
      • 超かっこいい
  • parallel query

    • クエリをストレージノードの数千のCPUにプッシュダウン
    • クエリを分解 -> 分解されたクエリにパラレルクエリコンテキストなるメタデータを付与
    • ストレージの台数分並列化する
      • 16並列まで?
  • Aurora Multi Master

    • Single Region Multi Master
    • Multi Region Multi Master
    • ダウンタイム0
      • アプリ側に対応が必要
    • conflict
      • 1つの条件でのみコンフリクト解消のプロセスが発動する
      • COMMIT先勝ち
      • パーティショニングすることがコンフリクトを軽減するために有効
    • Global replication physical
      • ちょっと何を言っているのか
      • 1sec以下の遅延
      • レプリケーション専用インフラが背後に自動で作成

Auroraのなかみ

  • キャシュレイヤーの分離
    • ヘッドノードにはいるが、DBプロセスにいない
  • カスタムエンドポイント

    • ヘッドノードのまとまりをつくれる
    • キャッシュの取り回しのために使うなど
  • Quoram

    • writerが6つのストレージノードに一斉に書き込み
    • 4つ以上のノードが完了したら、COMMITする
      • Vr + Vw > V
      • Vw > V/2
      • 少なくとも1つの共通のコピーを保持
      • 必ず重複するように
  • ストレージノードが10GBごとの論理ブロックに分割

    • なぜ10GBなのかはわからなかった
  • protection groupという単位
  • Auroraはクォーラムセットとエポックを使用
    • ノードの正常性が疑わしい状態になったらエポックが作成される
epoc1 abcdef

epoc2 abcdef(?)
      abcdeg(new)

epoc3 abcdef(NG)
      abcdeg(OK)
  • Auroraはデータページを全て送信することでレプリケーションしているわけではない
    • 差分のみを送っている