【データセンタ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を使っているけど、まだ使いこなせていないと感じている方は是非、要件をもう一度見直してみて下さい。
それではまた！
データを活用するための倉庫データウェアハウス（DWH）とは何か？
どうもKoheiです。
いい天気、いい気候、秋ですね。
今日はデータを扱う箱、データウェアハウスについて書きたいと思います。
1. データを活用するまでの道のり
これまで、データを管理するシステムであるRDBMS/NoSQLについて書いてきました。
リレーショナルデータベースについてまとめてみた - IT社員3人組によるリレーブログ
NoSQLとは？～大量データに対応したデータベースたち～ - IT社員3人組によるリレーブログ
さて、ではこれらを使ってデータ分析をするときを想像してみます。
例えば、先月の商品と売上状況をグラフ化します。
売上情報は売上管理システムで管理されていますので、このデータベースとレポートシステムをつなげます。
こうして、先月の売り上げを基に販売戦略を考えることができるようになりました。
すると、こんなニーズが出てきます。
売上管理システムでは、ユーザ情報も入っていました。
が、詳細なユーザ情報は別の顧客管理システムから取ってくる必要があります。
ということで顧客管理システムの情報も見れるように開発します。
頑張って顧客管理システムもつなげて見れるようにしました。
さあ、これでレポートを作って偉い人に報告します。
・・・また宿題をもらってしまいました。
さらに商談を管理するシステムとつなげたり、昨年度のデータも探さなきゃ・・・
あれ、売上管理システムは1年分のデータしか保持しないぞ・・・
詰んだ
と、なかなか大変になります。
一般に、業務システムは、顧客管理、売上管理など、それぞれ独立に存在しています。このため複数の情報を一元的に取りまとめてみたいとなると、各システムとの接続が必要になります。
しかも、もともと分析目的に設計されていないものだと、上の例のように情報が消えてしまったり、分析しやすい形になっていない、といったことが起こりえます。
こうした悩みを解決するシステムがデータウェアハウス(DWH)です。
2. データウェアハウスという考え方
データウェアハウス（Data warehouse）とは、その名の通り「データの倉庫」なのですが、提唱者のビル・インモン（William H. Inmon）によれば下記の４つの要素を満たすシステムだと説明しています。
1. サブジェクト指向：項目（ユーザ名、売上など）別にデータを分類し、保持する。
2. 統合化：複数のデータ媒体から情報を集約し、分析のためのデータを統合的に管理
3. 恒常性：入れたデータは基本的に更新・削除しない。
4. 時系列：分析のために必要な期間、データを時系列で保持・管理する。
こうしてデータを一元的にDWHに保存しておくことで、ビジネスに必要な情報を一元管理し、分析に役立てることができます。
DWHを実現するためには、データが成形され、利用目的が比較的はっきりしていることからRDBMSが利用されることが多いです。
ただし、汎用的なMySQLやPostgreSQLを使って・・・というよりも
・大量データを保持・管理する
・高速なデータ読み込みが求められる
という点で、それに特化したデータベース製品が適しています。
3. 主なDWH製品
以前RDBMSの紹介したものも含めてDWHとしてよく利用される製品を紹介します。
oracle database / oracle EXADATA
oracleが考えた最強のデータベースハードウェア「EXADATA」をベースとしたoracle database。安定感をほこるoracle databaseをSSDやらメモリやらモリモリ乗せたクラスタ構成のマシンで動かすことで、圧倒的なパフォーマンスを実現している。
SAP HANA
RDBMSのときにも紹介。大量データの高速処理が得意なインメモリデータベース。
IBM IIAS
ハードウェアとソフトウェアがセットになったアプライアンス製品。
IBM Db2をベースにデータ分析向けに性能向上。分散処理のソフトウェアであるApache Sparkや分析ツールも内包している。
teradata
名の通りtera byte級のデータを処理するために作られたデータベース製品。
独自の並列処理で高速なデータ処理を実現。Teradataは2018のGarnerの評価でもリーダーに位置する。
Amazon Redshift
初期構築費用不要のAWS上のDWHサービス。ペタバイト級のデータでもスケールアウトするので処理できるらしい。列指向型の並列処理で、大容量のデータに対しても、postgreSQLベースで高速なクエリ処理が可能。S3のデータをロードして1 時間あたり 0.25 USDから利用可能。
Azure SQL Data Warehouse
microsoft AzureのDWHサービス。分散計算＋分散ストレージと機能が分かれていて、それぞれ調整が可能。処理していないときはストレージ課金のみ。SQL serverとの互換性が高い。
Google BigQuery
Google CloudのDWHサービス。redshiftやAzure SQL DWに比べて、大規模データにさらに特化し、さらに高速と言われる。課金体系が時間ではなく、スキャンしたデータ量＆保持しているデータ量で、データを置いておくだけなら他と比べて圧倒的に安い(1/10以下)。リアルタイムな処理というよりは、月数回のデータ処理などに強い。
まとめ
データウェアハウスについてまとめてみました。
DWHに関連して、DWHの情報からレポートを作る際に用いるBI(ビジネスインテリジェンス)や、データウェアハウスよりもさらに幅広いデータを保持するデータレイクについてもどこかで書きたいと思います。
ではでは
LPIC(Linuc)て意味あるの？勉強法は？
どうも、ITコンサルタントのShoheiです。
古いMacをメルカリで売ってしまったためスマホからの更新になります。
前回のKeiくんのAWSの資格の情報に続き、今日はLPIC(現Linuc)に関する記事を書いていきたいと思います。
なにそれ
詳しくはこちら*1を確認いただければと思いますが、ざっくりいうとLinuxの基礎の理解を問われる資格です。
入社当初僕は先輩から「サーバー系ならLpic、NW系ならCCNAでとりあえず脱初心者証明しとけ」と言われてました。
資格の選定については賛否あるかと思いますが、資格の良さとかを考えて考えて何もしないよりはマシです。
僕が資格合格した時に「そういう資格結局あんまり意味ないからなー」とかほざく老害クソうんこジジイもいましたけど、繰り返します、何もしないよりはマシです。
何とるか迷って何もしないなら、有名な資格はさっさとっちゃえばいいと思います。
で、実際どうだったの？
さて、僕はLevel1,2,3全部取りましたが、実際のところとってよかったのか、実際取るべきなのかどうなのか、書いていきます。
良かった点
証明になる
「LPIC？ あー全部とりましたよ。」って言っとけば、「すごいかっこいい好き」となる人も少なからずいます。実際僕はLevel3までとってアピールしたら技術的な仕事(LPICと直接関係ないけどツール作ったり)が増えました。あとLinkedINなど転職系のSNSにもにもかける資格なので、客観的な証明になります。
普段業務で知り得ないことも一度頭に入れられる
後ほど書きますが、「これLpicの勉強でしかきいたことねぇぞ」て内容も出てきます。
「それ意味ないじゃん」て思うかもしれないてますが、逆にLpicを学んだ大勢の人は知ってます。
資格に載るということはどこかで出会う概念かもしれませんし、「見たことがある」状態にしておくことは一つ大事なことだと思います。
微妙な点
暗記が多い
特にLevel1。ググったりmanコマンドで調べれば一発の、しかも重箱の隅をつつく系コマンドも出てきます。それ覚えるのは割と苦行です。
あんまり体系的でない
「資格は体系的に学べるからいいよ」とよくききますが、サーバー系ってNWとかと違って全体像を絵に描きづらいようなところもあるので、知識を体系的に学んでる印象はないです。
体系的に知識を整理することを求めてるのであれば、あまりオススメしないです。というかサーバー系でそれをする手段があるなら教えて欲しいです。
各Levelの印象をちょっとずつ述べます
101
恥ずかしすぎますが舐めすぎて2回落ちました。しかも半年ぐらいダラダラ勉強してたかな(照)
基本コマンド、基本概念メイン。基本は暗記ゲーです。rpmとかyumとかの、こまかーいオプションがよく聞かれます。
ただシステムのブートの話は常識なのでちゃんと理解して覚えておくべきです。
102
101に2回落ちた後、3週間101を受けれなくなったので、その間に勉強して受かりました。
シェルの話はツールを書く人なら覚えておきましょう。
201
1で燃え尽きてやる気がなくなり、5ヶ月ほどダラダラ勉強してとりました(照)
システムの構築や保守やるなら、割と重要な項目が多いかと思います。
ストレージ管理のところは概念をちゃんとおさえておきましょう。
202
だるいので3週間でささっととりました。
Webサーバーなど色んなサーバーを構築していくコーナーですが、ここで勉強した知識をずっと覚えておくべきかというとNo。各サーバーの名前と存在は知っておくべきですが、実際の構築はケースバイケースなので、勉強した時の参考書を見返すことはないでしょう。
304
だるいので2週間でとって、満点でした。つまりそんな難しくないです。
そしてここまでくると内容が割と面白い。仮想化にまつわる細かい言葉の整理が出来るし、Pacemakerなどよく使うソフトの話も知れるのでなかなかよいです。
どうやって勉強したの
本で勉強
まず、このシリーズは一通り読みました。
Linux教科書 LPICレベル1 Version4.0対応
- 作者: 中島能和,濱野賢一朗
- 出版社/メーカー: 翔泳社
- 発売日: 2015/06/16
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (6件) を見る
Linux教科書 LPICレベル2 Version 4.5対応
- 作者: 中島能和,濱野賢一朗
- 出版社/メーカー: 翔泳社
- 発売日: 2017/05/12
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
Level3のときはなかったのでこちらでした。
![徹底攻略 LPIC Level3 304 教科書+問題集[Version 2.0]対応](https://images-fe.ssl-images-amazon.com/images/I/51nloW4BtnL._SL160_.jpg "徹底攻略 LPIC Level3 304 教科書+問題集[Version 2.0]対応")
徹底攻略 LPIC Level3 304 教科書+問題集[Version 2.0]対応
- 作者: 米山学,株式会社ソキウス・ジャパン
- 出版社/メーカー: インプレス
- 発売日: 2016/04/28
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (1件) を見る
ただ、これだけやってても落ちます。101のとき、あずき本の問題やり込んでましたが2回落ちました。
ネットで勉強
問題で練習するなら、絶対にPing-tがおすすめです。
色んな資格の練習問題が載っているサイトなのですが、間違えた数などに応じて各問題が金銀銅に色付けされます。
最初は銅ですが、正解すると銀に上がり、また正解すると金に上がります。間違えるとまた戻ります。
つまり、全てを二連続で正解しないと金にはならないので、三回解いてなお銅とか銀の問題は自分の弱点だと知れるのが非常に良いです。
試験前に全問題金にしてから臨みましょう。
Level2,3は有料ですが、Level1は無料です。
まとめ
Lpic(Linuc)の感想と対策方法についてまとめました。
