One life, One password その２
どうもhaseです。
前回SSOの話題を取り上げました。
今回はその実装方式について見ていきたいと思います。
実装方式の種類
wikipediaさんによると、実装方式は大きく5つあります。
上記4と5を合わせてフェデレーション方式なんて言い方もしますが、こちらが今後主流となる方式と言われています。
では実際に中身を見ていきます。
-
ケルベロス認証
とりあえず名前がかっこいい。冥界の番犬ケルベロス君に守ってもらえばどんなサービスも安心ですね。でもハリー◯ッターしかり、琴で眠らされて門番としては結構ザルなイメージが…笑
ザルイメージはさておき、ケルベロス認証はインターネットなど公開されたネットワークで使うために開発された認証システムです。仕様は、RFC4120やRFC4121で規定され、マイクロソフトのActive Directoryなどが対応しています。クライアントは、まず認証サーバーへとログオンし、シングルサインオンしたい各種サーバーの利用時に、チケット交付サーバーから利用先のサーバー用チケットをもらってアクセスします。
引用元：ケルベロス認証（Kerberos Authentication）とは
Kerberos認証では、チケットが盗聴されるとなりすましの被害を受ける可能性があるため、「時刻同期」によってその対策を実施しています。
チケットの中には、送信時刻（タイムスタンプ）が記録されていて、チケットを受け取ったサーバーが、チケットのタイムスタンプとそのサーバーの設定時刻とのズレが大きいと認証に失敗するようになっています。例えば、Active Directory環境では、初期設定で5分ずれると認証時にエラーが表示されるため、クライアント・サーバ間で時刻同期を実施しておく必要があります。
-
リバースプロキシ型
リバースプロキシ型のシングルサインオンは、Webブラウザからのアクセスを一度リバースプロキシサーバーが受け、そのリクエストをバックエンドに置かれたWeb サーバーに中継する構造を取ります。
引用元：https://boxil.jp/mag/a2411/
リバースプロキシへのアクセスが集中してしまうため、負荷分散等は必須であるものの、アプリケーションに依存せず、セキュアな認証を構築できます。
ユーザ数が少なく、アプリが多い場合に向いていると思います。
-
エージェント型
エージェント型とは、アプリケーションサーバー自体に仲介役の「エージェント」というソフトを入れる方法です。HTTP cookie(クッキー)が利用されます。
引用元：https://boxil.jp/mag/a2411/
リバースプロキシ型と違い、ネットワーク構成を気にしたり、負荷分散等を考える必要はありませんが、Webサーバごとにエージェントを入れる必要があったり、Webサーバがエージェントに対応していなかったり、エージェントの管理がちょっと大変そうです。
ユーザ数は多いけどアプリが少ない、なんて場合に向いてるんじゃないでしょうか。
-
フェデレーション方式
SAML, OpenIDについての詳細は次回に譲るとして、まずはフェデレーション方式について概要を説明します。
フェデレーション方式とは、クラウドサービス間を、パスワードの代わりにチケットと呼ばれる情報を受け渡しすることで、シングルサインオンを実現する方式です。
引用元：https://boxil.jp/mag/a2411/
この方式の画期的なところは、異なるドメイン間でSSOが実現できるという事です。というよりも、クラウドサービスの目覚ましい発展を受けて、それらに対してSSOを実現するために標準化（SAMLやOpenIDなど）されつつあるのがフェデレーション方式です。そういった意味で、今後主流になっていく、と言われています。実際、「Office365」、「G Suite」、「Salesforce」、「Box」など、多くの海外クラウドサービスが対応しています。
まとめ
SSOを実現する方法について幾つか触れました。
データレイクとは？DWHとどう違うの？
どうもKoheiです
三連休、いい天気が続きそうですね。
前回までの記事でデータウェアハウス（DWH）＋BIを中心とした解析環境の話をしておきました。
今日はデータレイクについて書きたいと思います。
データレイクとは？
みなさんはデータレイクという言葉は聞いたことがあるでしょうか？
2010年ごろにBIツール企業のPentahoのCTOであるJames Dixonが提唱した考え方で、構造化されたデータ、非構造なデータ問わず、あらゆる分析で利用する可能性のデータを保持することのできるシステムのこと。。。と言われています。
「考え方」というところがポイントで、こういう技術を使えばデータレイクになる！というような明確な定義がありません。
データレイクが実現すること
定義が曖昧なデータレイクですが、 データレイクを通じて実現したいことは下記のとおりです。
- 構造・非構造など形式に関わらずデータを蓄積できること
- 生成されたのと同じ形式の生データを持つこと
- 必要に応じてデータをピックアップし、加工・解析ができること
昨今IoTの発展や通信の大容量化により、テキスト、画像、動画、音声といった様々な形のデータが増え続けており、こうしたデータを解析して、次のビジネスにつなげることが必須になってきました。
こうした非構造なデータも含めて、まとめて貯めて置いて必要に応じて解析したい
というニーズを満たすのがデータレイクになります。
DWHとの違いは
以前説明したデータウェアハウス(DWH) も「データの倉庫」としてデータ解析のためのデータを保持するシステムとして紹介しました。
DWHとデータレイクの最大の違いは、
分析目的に基づいたデータ設計がなされているか？
という点です。
DWHは主にRDBMSを使うケースが多く、それゆえ、分析したい要件に応じて事前にデータを加工・整理しています。
一方、データレイクは、まだ具体的な分析要件が固まってないけど、とりあえずためておくとなんか使えるかも、くらいの目的でデータを保持します。
つまりDWHより、より柔軟な分析要件にこたえられるような対応を想定しています。
データの沼地
とはいえ、
ストレージ買ってきてデータをとりあえずデータを突っ込んでおけばokでしょ！
データレイク完成！
とすると落とし穴にはまります。
ただやみくもにデータを貯めておくと、誰からも使われないデータ置き場になり、「Data Swamp(データの沼地)」になってしまうケースがあります。
- 必要に応じてデータをピックアップし、加工・解析ができること
これを満たしていることが肝になります。
なので、単にデータストアとしての一面だけでなく、どんなデータが蓄積されているのかというメタデータ管理の側面も持ち合わせています。
データレイクを実現するアーキテクチャ
さて、最初にも言いましたが、データレイクを実現するための必須アーキテクチャは存在しないです。
要件に応じてNoSQLデータベースを作るかもしれません。
あるいは大容量のオブジェクトストレージを用意するかもしれません。
多種多様なデータを生情報として保持し、解析する際にピックアップできればokなわけです。
・・・とはいえ、データレイクとして使われるのに主流のアーキテクチャは存在します。それが以前も説明したHadoopになります。
Hadoopがデータレイクとして適しているのには下記のような特徴を持つからです。
Hadoopの分散ファイルシステム「HDFS」によって様々なファイル形式のデータを保持することができる
これは、データレイク要件の中の
構造・非構造など形式に関わらずデータを蓄積できること
生成されたのと同じ形式の生データを持つこと
を満たします。
hadoopのコア技術である分散ファイル処理によって、多種多様なデータを保持することができ、容量が足らなくなったらサーバを増やすことでスケールアウトも容易です。
MapReduceやほかのHadoopエコシステムを通じて、HDFSに保存されているデータへのアクセス・加工が容易に行える
データレイク要件の中の
必要に応じてデータをピックアップし、加工・解析ができること
に該当します。
hdfsに保存されているデータに対しては、MapReduceを使った分散処理が可能です。
また、Hadoopエコシステムと呼ばれるHDFSへのアクセスや分散処理を簡単にするためのフレームワークがたくさん作られています。こうしたフレームワークを使えば、例えば、大容量データをSQLで簡単に処理したり・・・といったことも可能になります。
まとめ
データレイクについてまとめてみました。
データを蓄えて、ちゃんとデータをピックアップできればなんでもあり感があるデータレイクですが、きちんと保存したデータを活用できるように「メタ情報を管理すること」が要になります。データの沼地にならないように、よく考えてデータレイクを作って利用していくことが大事ですね
ではでは
【データセンタNW】Cisco ACIについて①
どうも、Keiです。
最近AWSネタばかりだったので、今回は久しぶりにネットワーク（以下NW）について取り上げてみたいと思います。
特に、今回はデータセンタ内ネットワークなどのインフラ技術として注目を集められているCisco ACIについて話していきます。
まず、Cisco ACIって何？って方もいることかと思います。
そのため、今回はブログを2回に分けて書いて行きたいと思います。
第1回である今回はCisco ACIとは？という所から、Cisco ACIを理解する上で避けられないファブリックという概念を紹介します。
第2回では、ファブリックを使って柔軟なSDNソリューションを実現するACIのメリットについて書いていきたいと思います。
クラウドに適したNW
さて、第1回の冒頭ではCisco ACIが登場した背景から説明します。
普通の方なら、ネットワークといえばL2スイッチ、L3スイッチ、ルータから構成された一般的なネットワークを思い浮かべるかと思います
そして、そこには無線ルータやハブ経由でご家庭のPCやスマホが接続したり、企業NWならサーバが接続されますよね。
今までなら、これで良かったんですけどね。
一方で、皆さんがご存知のように昨今はクラウドが世界中で展開されています。
非常に完結に言うと、このクラウド化によるネットワークの使い方だったり、トラヒックの流れ方が変化したことにより、従来のネットワークでは非常に無駄が多くなってしまったため、クラウドに適したネットワークの仕組み「Cisco ACI」が誕生したのです。
もう少し詳細に説明しますと、クラウド以前の環境ではご家庭のPCからインターネットのサーバにアクセスしてた状況が、インタネット間の通信が増加しているという状況です。
もっと言うとデータセンタ内のVM間の通信が増えたという状況です。
VMも物理サーバと変わらずIPアドレス、MACアドレスを持つので、通常VM間で通信する場合はVLANみたいな形で似たシステム毎にVLANを切って接続するのが常です。
一方で、VMは仮想化の特徴を持っているため、物理サーバとは異なる性質があります。その代表的な特徴として、VM Wareのvmotionのように、VMを停止させずに物理ホストを移動させることができることです。
利用者にとっては非常に便利なこの機能ですが、従来のネットワークではこの速度には対応できません。スイッチやルータを組み替えてVLANの設定を変更して。。と非常に面倒ですし、手動だし。。。ということになってしまいます。
このように、クラウド化が進むとネットワークもクラウドに合わせて進化する必要があります。
Cisco ACIはこのようなクラウド化に伴うネットワークへのニーズによって生まれたNWサービスなのです。
Cisco ACIを支えるVXLAN技術
さて、前のトピックではCisco ACIではVMなどの仮想デバイスの物理的な構成変更にネットワーク側もハードウェアの設定（スイッチのVLAN設定やルータの設定）を変更せずに対応可能という話をしました。
これを実現する技術がVXLANという技術です。
名前はVLANに非常によく似ていますね。実際、VLANのような役割も持っています。
一方で、VLANはあくまでスイッチで設定する物理に近い技術ですが、VXLANはよく「Layer2 over Layer3」と言われるオーバーレイ技術です。
知っている人はわかるのですが、知らない人はここで一気についていけなくなると思います。
「Layer2 over Layer3」を知るには、先にVXLANで具体的に「何」が可能になるかを言った方がいいかと思います。
ずばりVXLANで可能になることは「L2延伸」です。
例えば、あるオンプレ環境があり、これをクラウドに持っていく際にシステムの制約から異なる2つのデータセンタにサーバを配置する必要があるとします。
ここで、オンプレ環境でL2で接続していたVM同士が別々のクラウドに分かれることで、L2での接続はできなくなります。
そのため、オンプレで使用していたIPアドレスは使用できなくなりますよね。ここで、IPアドレスは様々なシステムに波及する可能性があるため、なるべく変更したくないものです。
そこで、どのようにするかというと図でいうデータセンタAとデータセンタBをL2で結ぶ（L2延伸）ことをします。
この技術はいくつかあるのですが、VXLANはこれを可能にします。
VXLANはL2フレームをL3ヘッダ（VXLANのプロトコル）でカプセリングします。
例えばデータセンタAのVMからデータセンタBのVMに送信されたL2フレームはVXLAN対応の装置によって、L3のカプセリングが行われます。これによって、送り先のIPアドレスはデータセンタBのVXLAN対応ルータとなります。
後は、カプセリングされたデータは普通にルーティングされ、データセンタBのVXLAN対応ルータに届きます。ここで、L3ヘッダは取り除かれ、L2フレームが取り出されます。
このように、L3ネットワークを超えてL2フレームをやりとりすることを可能にするため、VXLANは「Layer2 over Layer3」と呼ばれます。このようなアンダーレイの物理ネットワークに依存しない形態をファブリック、またはIPファブリックといいます。
VXLAN対応が取り付ける、L3ヘッダにはVXLANのタグが含まれますが、これがVLANでいうタグに当たるものです。これによってどのVMに渡せばよいかを判別しています。
このタグは、L2、L3の上にオーバレイとして設定しているので物理的なスイッチやルータを変更する必要はありません。
これが、従来のネットワークにはなかった柔軟性がVXLANにある理由なのです。
さて、今回はCisco ACIを支えるVXLAN技術について紹介をしました。
次回はCisco ACIのファブリック以外のコントローラ部分について、ユースケースとともに紹介をしたいと思います。
それでは！
NoSQLの整合性担保 -AmazonとGoogleの思想の違い(Part2)
どうも、ITコンサルタントのShoheiです。
今日は僕の前回記事の続きで、NoSQLの主要2種について解説をしていきましょう。
少しだけ前回のおさらい
前回、NoSQLのアーキテクチャには２タイプあるという話をしましたね。
GoogleのBigtableはマスタ型を取っており、AmazonのDynamoはP2P型です。
またCAPの定理により、Consistency(整合性), Availability(可用性), Partitions(分断体制)の3つを同時に満たすことはできない、という説明をしました。
複数ノードでの稼働を前提とすることが多いNoSQLではPを譲らないものが大半という話もしました。
下の図のように、Dynamo系はAP,Bigtable系はCPを担保するDBと言えます。
ではここからは、Dynamo系とBigtable系の違いについて、もう少し突っ込んで説明していきましょう。
整合性担保の仕方の違い
異なる点の一つとして、整合性の担保の仕方が違います。
その前に整合性の解説ですが、整合性とは、読み出したデータが矛盾を生まないこと、でしたね。
下の図は、整合性が担保されていない例です。
データが複数ノードで読み書きされるケースを想定していますが、同時に犬さん口座からの引き落とし作業と振り込み作業が行われた際、両方が両方のリクエストをそのまま受け付けているために、データが一致しなくなっています。
これでは、システムの何を信じたらいいかわからない致命的な状況になっています。
RDBの場合の整合性担保方法
では、従来型RDBでどのようにこの整合性を担保してきたかについて、一例を挙げて説明します。
下の例では、書き込みの受付をノードAに絞っています。もし同じレコード(この場合"犬さん残高")への書き込みが同時にあった場合、一方をブロックしています。
少し正確に言うと、"5千円の引き落とし"というクエリが走っている間、"犬さん残高"のレコードへの書き込み(または読み書き)はロックされています。
ロックはいつ解除するかというと、書き込みに関連する作業が全て終わったタイミングです。諸々設定やポリシーによりますが、例えば、更新があった箇所をノードAのディスクに書き込み、ノードBにその変更を伝えたタイミング、などとなります。
ノードBは何のために存在するかというと、データを失わないためのバックアップであったり、読み専用のノードだったりします。あくまで書き込みはノードAですべて受け付けよう、というものです。
ただ御察しの通り、書き込みの受付が一つのノードに限定されるということがネックになり、大量の書き込みが行われるWebシステムなどでは限界がある、というのが難点です(複数ノード書き込みを許容するRDBは少ないのです)。
Bigtableの場合の整合性担保方法
Bigtableの場合、書き込み自体はどのノードでも受け付けます。
ただし、どのノードがどのレコードに関する書き込みを受け付けるかが、決まっています。
例えば以下のように、ユーザIDが偶数の場合はノードAで書き込みを受け付け、奇数はBで、というもの。そして書き込まれた変更点は同期的に複数ノードに伝えられ、そこまで完了してから書き込み完了とします。
こうすることで、書き込み対象のノードを分散させつつ、同時書き込みによる不整合を防ぐことができます。
またもっというと、ノードをさらに追加しても、自動で担当を振り直してくれます。「じゃぁ僕はユーザIDの末尾が1,4,7のものを担当するよ、君は2,5,8ね、君は3,6,9をよろしく」といった具合にです。また「ユーザID末尾が1のものが書き込み多くてノードAが辛いから、4,7の書き込みはノードBとCに担当してもらおう」という負荷分散も行われます。
Dynamoの場合の整合性担保方法
さらっと書きましたが、上記の例では変更内容は複数ノードに同期的に伝えられるため、不整合が生じることはほとんどありません。これは「強い整合性」と言われており、ノードによって異なる値をもつというのを禁じるのがポリシーです。CAPのCが強く守られているのがこのパターンです。
一方Dynamoの場合は「弱い整合性担保」がポリシーです。
これは一体何かというと、「いや、たとえ全てのデータベースで同じ値を持ってなくても、結果的に正しいものがどれかわかればよくね？」という考え方です。
そのための考え方の一つであるQuorumについて簡単に説明します。
Quorum(クォーラム)とは
Quorumは、元々「(議決に必要な)定足数」というい意味です。Quorumによる整合性保証は、以下のように表されます。
R+W>Nの場合、整合性が保証できる
N:レプリカの数
R:ノードから読み出す数
W:ノードに書き込む数
意味がわからないと思うので、まずはこの原則が満たされていない例から説明しましょう。
以下のように、読み込みたいデータが３つのノードに格納されているとします（N=3)。
最新情報は１つのノードだけに書き込まれました(W=1)。
この状態で一つだけのノードからデータを読みだした場合(W=1)、残念ながら正しいデータ(書き込みが反映されたノードが持っているデータ)を読みだせる確率は1/3ですね。2/3の確率で間違ったデータを引いてしまいます。これは、R+W(=2)<N(=3) であることからわかるように、Quorumの原則が満たされていません。
確率が低ければいい、という話でもなく、間違ったものを引いてしまう可能性がある時点で、データベースとして使えなくなってしまいます。
では、上記の原則が満たされている場合はどうでしょうか。
以下の例をご覧ください。
ここでは N=3, R=2, W=2です。
R+W(=4)>N(=3)となっており、Quorumの原則を満たしていますね。
そのため、たとえ読み込んだ2つのノードのうち、一方の情報が古かったとしても、もう一方の情報を採用することで正しいデータを引いてくることができます。
ただし、お察しのように、WとRの数を増やしているので、その分処理時間は長引いてしまいます。
上記の例では、書き込み時刻(Timestamp)が新しいものが勝つというシンプルなルールでした。ただサーバ間で完全に時刻を一致させることが難しいなどの壁もあります。
他の整合性担保方法として、ベクタークロックなどの技術もあるので、もし興味があれば調べてみてください。
まとめ
今日は、BigtableとDynamoの整合性担保の方法の違いについて説明しました。
次回はそれぞれでどのようにデータ書き込み先を判断しているか、もう少し詳細にお話ししたいと思います。
BIとは？データ可視化のBIツールをまとめてみた
どうもKoheiです。
寒くなってきましたね。
前回までデータを効率的に管理するためのデータベースについて書いてきました。
さて、今日はいよいよデータの可視化の核となるBI（ビジネスインテリジェンス）について書きたいと思います。
BIとは？
「データの可視化」まではよく聞いたことありますが、BIって皆さん聞いたことあるでしょうか？（僕は仕事で触れるまで知りませんでした・・・）
BIとはBusiness Intelligenceの名の通り「データからビジネスに役立つ知見を見つけ、経営判断などに利用する手段」のことを言います。
つまり、単にデータを可視化するだけでは足りなくて、そこから何か知見を発見し、ビジネスに活かすことまでを目指しています。
こうしたBIを推進するのがBIツールです。
もはや今の時代にBIツールを使っていない大手企業はほとんどいないんじゃないかと言われています。
BIツールが実現すること
BIツールが提供する機能として以下のものがあげられます。
レポーティング機能
いわゆるシンプルなデータの可視化機能。
複数のデータを結合して、折れ線グラフや縦棒・横棒グラフなど多様な形で表現することで、数値から読み取りにくい量の比較や増加傾向などを一目で読み取ります。
ダッシュボード機能
レポーティング機能で作ったグラフを組み合わせてひとつの画面にすることで、一目で多用な尺度からの情報判断を可能にします。
OLAP（多次元分析）
OLAPとはOnLine Analytical Processingの略であり、オンラインにデータを多次元的な視点で分析・可視化する処理のことを言います。
難しい感じですが、例えば先月の売り上げダッシュボードがあったら、「商品Aはどんな売り上げだったのか？」 「1週目は何が売れていたのか？」といった軸で条件を変え、その場でグラフを変化させて、要因分析をするイメージです。OLAPによって様々な条件結果を瞬時に提示することができます。BIツールが活きる部分です。
シミュレーション機能
将来○○だったら数値はどうなるのか？という仮説検証を実現します。
BIツールの製品例
2018年のGartnerレポートによれば、次の3社がBI platformのリーダに格付けされています。
Tableau
ビジネスインテリジェンスとデータ分析 | Tableau Software
BIツールとしては世界で圧倒的なシェアを誇る。
直観的操作でデータを簡単に可視化できるところに強みを持つ。凝らなくてもグラフもキレイ。様々なライセンス形態があるが、企業向けならユーザ課金で年間50000円/人から
Microsoft Power BI
Microsoftの出しているBIツール。
Excelベースのインタフェースで簡単に大容量データの可視化ができる。Excelユーザにとって使いやすい。ユーザ数課金と容量課金方式がある。データ量が少ないうちは年間13080円/人なので、tableauよりコスパよい。
Qlik Sense
Qlikは1993年にスウェーデンで誕生したBIをメインとする企業。
見た目はtableauの方がキレイと言われるが、データ連想技術と言われる独自の圧縮技術で勝手にデータの関係性を把握してくれる。インメモリDBを内包して、データを一元管理する役割も持つ。
新しいBIツールたち
その他、スタートアップ企業の製品やオープンソース製品も多数登場しています。
looker
個人的にも気になっているBIツール。まだ2013年にアメリカで登場したばかりだが、yahooやgithub、最近ではメルカリも導入を決め勢いのあるスタートアップ企業。lokker自体がデータを保持するのではなく、外部のdwhなどのデータソースを使う前提。レポートをコードとしてgithub連携できたりとユニークな機能を持つ。
re:dash
オープンソースのBIツールでは一番有名どころではないだろうか。比較的シンプルなグラフとダッシュボードを持ち、SQLでクエリを書く前提だったり、pythonが実行できたり、といろいろできる分、少しエンジニア向け。trialなら無料で、機能豊富な有料版はデータソースやダッシュボード数に応じた課金体系だが、tableauなどに比べたら圧倒的に安い
Superset
Apache Superset (incubating) — Apache Superset documentation
こちらもオープンソースのBIツール。re:dashに比べてグラフ表現が強く、SQLを書かなくてもキレイなグラフがかける。データベースの接続設定がやや煩雑。
metabase
こちらもオープンソースのBIツール。re:dashと比べて、操作性に優れ、GUIの操作も可能なので非エンジニアも利用しやすい。サーバリソースはre:dashに比べてやや高い。
まとめ
ここまでBIツールについて、その機能と製品例をまとめました。
他にもAWS, Azure, GCPでもダッシュボードツールがあったり・・・と非常に選択肢の種類の多い分野になっています。
BIツールを入れたからといってデータが活用できるとは限らずBIが実践できないケースも数多くあるそうです。環境にあった適切なBIツールを選定することが大切だと思います。
ではでは
NoSQL -AmazonとGoogleの思想の違い
どうも、ITコンサルタントのShoheiです。
ようやくMacBook Airが到着しました。最高です。
さて、今日は以前Koheiの記事で紹介のあったNoSQLについて、もう一歩だけ踏み込んで議論をしてみましょう。
アーキテクチャには二種類ある
上述の記事では、3つのデータモデルについて説明がありました(カラム志向型データモデルも加えて４つで説明されることもあります)。
今度はデータの持ち方、ではなくアーキテクチャーに目を向けてみると、大きく2種類に分類することができます。
図の左側に描いたものは、マスタ型と呼ばれていて、図の頂点部分にあたるマスタノードが配下にあるノードたちを管理する、という構図になっています。GoogleのBigtableがこの構造を採用しています。
一方左側はP2P(Pear to Pear)型と呼ばれます。AmazonのDynamo DBがこの構造です。こちらでは、Google系のようにマスターノードを立てるのではなく、個々が互いを管理する形になっています。
これらの特徴について、簡単に見ていきましょう。
2つの派閥
比較をしていく前に、Bigtable系／Dynamo系について簡単に説明しましょう。
それぞれ論文が発表されています。
例えばBigtableの論文には*1、以下のように、Googleのいろんなサービスの中で実際に使われていることが述べられています。
Many projects at Google store data in Bigtable, including web indexing, Google Earth, and Google Fi- nance.
またDynamoの論文*2 に関しても、Amazonサービスのコアであり、ショッピングカートなどの裏側の技術として使われていることも記載あります。
それぞれの論文には、DBの中身のアーキテクチャまで解説がしてあります。それもあり、この二つは他の多くのNoSQL製品にも影響を与えてきました。
そのため、マスタ型・P2P型のところに上ではBigtable系／Dynamo系と記載をしています。
なお、前回記事のデータモデルの話と今回のアーキテクチャの話を表にまとめると、以下のようになります。*3
※イネーブラ型は一旦無視してください
Bigtable系とDynamo系の違い
さて、話を戻しましょう。
上述のマスタ型とP2P型、これらのアーキテクチャの違いは何を生むのでしょうか。
結論から先に言うと、DBとして重視するポイントが違います。
重視するポイントについて考えるにあたり、一つ押さえておかなければならない概念があるので説明します。
CAPの定理 :CAPとは
整合性(Consistency),可用性(Availability),分断体制(Partition Tolerance)の頭文字をとって、CAPと総称される概念があります。
それぞれの意味は記載の通りなのですが、Partitionsだけあまり今までのRDBMSだと意識されてこなかった言葉ですかね。
RDBMSの場合、書き込みを一台のマスタサーバにだけ行うことが多いのですが、一方でNoSQLは大量のサーバにデータを置いて読み書きするような使い方が想定されます。
この時、ノード間でデータを冗長化している場合、どんな問題が生じるでしょう。
一つ考えられるのは、あるノードに書き込んだ際、裏でノード間同期が走るかと思いますが、その際にノード間の通信が障害によりできなくなったら、つまりNWが分断されたら、データが書き込まれたことを他のノードに伝えられなくなります。そして不整合が起きる可能性が出てきます。この状態を、分断体制が弱いと言います。
CAPの定理とは
さて、CAPが何かわかったところで、CAPの定理に戻りましょう。
中身だけいうと、分散システムにおいては、CAPのうち、2つしか同時に満たすことができない、という法則です。言い換えると、分散システムでDBMSを実現するには、CAPのうち一つを犠牲にしなければならない、ということです。
改めてDynamo系とBigtable系の違い
さて、上でDBとして重視するポイントが違いますと述べましたが、もうわかったでしょうか。そうです。Dynamo系とBigtable系では、CAPのうち犠牲にしているポイントが違います。
超ざっくり書くと以下のようになり、Dinamo系はAP, Bigtable系はCPを選択しています。またRDBMSは前述の通り、あまり複数ノードによる分散制御を意識していなかったのでACを選択しています。
どんなイメージ？
AP重視とCP重視といっても、どんなイメージかわからないかと思うので、イメージを絵に描いておきます。
ただ、APの場合についても、やはりDBでデータの不整合が起きることは致命傷なので、BASE特性という特性を備えさせることで、弱い整合性を担保しています。
この辺りは話し始めると長くなるので、より具体的なアーキテクチャとともに次回説明していきましょう。
まとめ
NoSQLのアーキテクチャの概念と、CAPの定理について説明しました。
*1:https://static.googleusercontent.com/media/research.google.com/ja//archive/bigtable-osdi06.pdf
*2:
https://www.allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf
*3:"NOSQLの基礎知識", 太田洋=監修,本橋信也・河野達也・鶴見利章=著
AWSを使う上で意識すべきこと【3選】
どうもー、Keiです。
最近、Taylor Swiftの昔のカントリー調の曲「white horse」「you belong with me」「mean」とかを聴いていたら、今とのギャップにめちゃくちゃ切なくなりました。
今や「bad blood」ですよ・・・。人ってそんな変わります？
さて、今回はAWSを使う上で意識した方がいいことを3つまとめてみました。
今やクラウドサービスはAWS以外にもMicrosoft Azure、GCP、IBMクラウドなどがありますが、AWSが出た当時は明確にAWSを使うメリットがありました。
その根幹の部分は現在も同じです。
逆に今回上げる5つが、自分が設計したいシステムの要件にない場合はAWSを使う必要はありません。
使ってないシステムはオフに
これは、クラウドを使いたい人にとって最大級の要望だと思います。
例えば、普段はぜんぜん処理がないが、1日の終わりにまとめてバッチ処理をするようなサーバがあった際に、このサーバを1日分借りるのはもったいない感じがしますよね？
1日の終わりに処理する際に、必要なリソースを起動させて従量課金的にコストを計算してもらった方が嬉しいですよね。
EC2に代表されるサーバインスタンスは、1秒単位の重量課金制を持っている上に、次のトピックでも説明するオートスケールにおいて、ミニマム0台のオートスケールの設定ができます。
これによって、本当に処理やアクセスがない場合はEC2が1台も起動しない状態を作ることができます。
ちなみに、個人的にすごいな～と思ったのは、AWSではAmazon GameLiftというサービスです。これはマルチプレイヤーゲームの基盤を提供するサービスで、一般的に1日の中でアクセス数に波のあるマルチプレイヤーゲームに対して、アクセス数が少ないときは、計算処理のリソースを少なくすることでコストを安くして、逆にアクセス数が多いときはリソースを増強するというものです。
非常にAWSのサービスとマッチしているので、ゲームの基盤というプラットフォームにもAmazonの強みを出せるサービスだと感じました。
スケールアップでなくスケールアウト
スケールアップとスケールアウト。IT業界にいるとよく聞くスケールという言葉。
ご存知の通り
スケールアップとは、処理の増加に対してマシンのCPUやメモリを大きくする方法です。例えば、EC2だとインスタンスのスペックをmicroからlargeに上げることです。
これに対して
スケールアウトは、マシンのCPUやメモリはそのままで、マシンの台数を増やすことで処理を並列実行するというものです。EC2の例だと、largeで10分かかる処理をmicro10台で同じ時間で処理するという方式です。
ここで、スケールアップよりスケールアウトと説いているのは、スケールアップするためにはアクティブで動作しているインスタンスを停止して、スペックの良いインスタンスを起動させるのに時間がかかってしまうからです。
また、AWSではマシンに必要な性能を、最大負荷試験などのマシンスペックを見極める試験をみっちり1カ月やって設計するのではなく、短い期間でマシンスペックを決めて、性能により処理が追い付かない場合は「オートスケール機能」を使ってスケールアウトさせようという考えがあります。
これは最大負荷試験をやったことがある方なら良くわかることかも知れませんが、ぶっちゃけ試験に時間をかけても精度が比例して大きくなる訳ではないし、予想外の上振れ要因もあるので、クラウドならではのやり方でこれを解決できるなら使わない手はありません。
マネージドサービスで保守運用を楽に
最後はマネージドサービスを使おう！というトピックです。
AWSは、EC2、データベース、ストレージ、ロードバランサなどサービスが星のように多く、組み合わせて使う運用・保守が大変そうというイメージがある人も多いかと思います。
一方で、マネージドサービスと呼ばれるハードやミドルウェアの管理はAmazonが行うから、ユーザはソフトウェアの開発に専念してどうぞ～というサービスがあります。
確かに、より柔軟なサービスを提供するには時としてAmazonのマネージドサービスでは実現できない要件もありますが、もしマネージドサービスが使える場合は是非とも使っていきましょう。
スピード感の大事なソフトウェア開発では、運用・保守のルールやガイドラインの整備などをしている暇がなく、短納期で成果物を納品する必要も時としてあるでしょう。
このような際にAWSのマネージドサービスは、煩わしいハードやミドルウェアの管理を肩代わりしてくれるので非常に便利なサービスです。
さて、今回はAWSを使う上で特に大事な考え方を挙げてみました！
現在AWSを使っているけど、まだ使いこなせていないと感じている方は是非、要件をもう一度見直してみて下さい。
それではまた！
