ベイズの定理の導出から, モンティ・ホール問題への応用まで.

ベイズの定理の導出

事象 $A$ が発生する確率を「$P(A) = A$ が発生する確率 $\div$ すべての事象の数」と書くとき, ベイズの定理は

と定義される. 以下ベイズの定理を導出する. 例として, 起こり得る全ての事象の数を $200$, 事象 $A$, 事象 $B$(以下単に $A$, $B$ と書く)が発生した回数をそれぞれ $60,\ 40$ とし, $A$ および $B$ が発生した確率を $10$ とする. 簡単のために, この事象関係を表すベン図を次に示す¹.

以前の記事, エルガマル暗号では, エルガマル暗号に関する諸々の前提の説明と, その実装について示した. 同エントリ内で, フェルマーの小定理¹については取り扱ったものの, その一般形であるオイラーの定理およびカーマイケルの定理について特に触れなかったため, 本エントリでそれらに関してまとめる. しばしば値の確認には, 簡単のため Haskell を使う.

本エントリでは, VPC-EC2 で MASTER 側のヘルスが確認できなくなったときに, VRRP を用いてフェールオーバし, 一定度の可用性担保を実現する場合について¹取り上げる. VRRP の実装としては keepalived を用いることとする.

前提

次のシチュエーションを前提としている.

• インスタンスが 2 つ以上作成済みで, 24, 80 番ポートを SG の設定で開けてあり, どちらにおいても apache2 と keepalived が稼働している.
• keepalived.conf にそれぞれ MASTER と BACKUP が設定済みで, VPC-EC2 のルートテーブルにて, いまの設定にあわせて 1 つに VIP (192.168.1.1/32) が設定してある.

このシチュエーションがオンプレミス環境上の話であれば, 何の問題もなく, これでフェールオーバが実現できるのだが, AWS EC2 でこれを実現するためには, AWS のルートテーブル側の VIP ターゲットをも貼り直す操作が必要となり, この操作については, ある程度自分で実装しなければならない. いくらか調べて見ると, awscli で同様の環境を作っている事例を多く見るのだが, 本エントリでは諸事情より AWS SDK for go を使って, 操作することとした.

学校の関係で MySQL を触る機会が増えてきたので, MySQL の C++ 向けライブラリを一度触っておこうという忘備録.

これを実行すると, 次のように, 実在しそうでしなさそうな, 妙に怪しい雰囲気¹の一覧が出力される.

エルガマル暗号が離散対数問題の応用であることは認知していたものの, きっちりと自分でまとめたことが無かったと思うので, それに関連する諸々の前提についてもふまえて, 一度書くことにした. また, その処理系を実装した. 本エントリでは, 同暗号プロトコルの話の前にまず前提を示し, その後, 実装の観点から見た要点を示す.