データを活用するための倉庫データウェアハウス（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)の感想と対策方法についてまとめました。
AWS Solution Architect Associate合格しました！【2018/11時点】
どうも、Keiです。
最近飲み会が少ないおかげで体調がすこぶる良いです。やっぱアルコール漬けの生活って害悪っすね。
さて、いきなりですがAWS SAA（Solution Architect Associate）に合格しました！
今回は合格までの勉強方法や試験の内容について書いていきたいと思います。
AWS SAAって・・・？
そもそもAWS SAAって何？って方のために最初に簡単に内容を
説明したいと思います。
AWSの資格は以下の３つのカテゴリに分けることができます。
- Solution Architect（設計）
- Developer（開発）
- Sysops（運用）
- Solution Architect
こちらは、クライアントの要望を満たすために数あるAWSのサービスを組み合わせて最適なシステムを設計するための資格です。
AssociateとProの２つの難易度があり、Associateに合格しないとProは受験できません。
Twitterのリプで、現在はassociateを合格しなくてもproを受験可能なようです。詳細はこちらからどうぞ。 - Developer
AWS上で、アプリケーションの開発を行う人向けの資格です。Solution Architectと比較するとより１つ１つのサービスに触れていないとわからない問題が出るので、AWS上でコードを書いたり等、実務経験がないと難しいかもしれません。 - Sysops
こたらは、AWSを運用する上での知識やベストプラクティスを問われる資格です。DeveloperやSysopsの範囲もSolution Architectと一部被っていますがより、開発や運用面の詳細な知識が求められます。なぜ、範囲が被っているかといいますと、設計をする際は開発や運用がしやすいように設計する必要があるからです。
さて、AWS solution architect associateは今年の2月時点に新形式がリリースされ、8月13日には旧形式の試験は受けることができなくなりました。
現在は、問題数65問、時間130分のなかなか長い試験となっています。
勉強方法について
勉強した内容についてまとめてみました。
- 勉強時間：15日（45時間程度）
- 勉強資料
・AWS認定ソリューションアーキテクト（4周）
・公式サンプル問題
・有料模擬試験（1回）
・Blackbelt（主要サービスは2周）
AWS認定 ソリューションアーキテクト
勉強に使った参考書は下記の本です。
合格対策 AWS認定ソリューションアーキテクト ?アソシエイト
- 作者: 大塚康徳
- 出版社/メーカー: リックテレコム
- 発売日: 2016/10/14
- メディア: Kindle版
- この商品を含むブログを見る
2016年に出た本ですが、試験に出やすい主要なサービスについて、これまた試験に出やすい部分にスポットを当てて紹介しています。非常におすすめですし、ここに書かれている内容は細かい内容（IOPSなどのパラメータ）含めて全て暗記すると良いと思います。
一方で、もう2年も経っているのでけっこう古い情報が多いです。
例えば、S3のSLAの低い安いオプションであるRRSは、現在ではS3の価格改定によって、コストの面から最適なオプションでなかったりなど。
模擬試験
AWSでは有料の模擬試験を受けることができます。
現在30分で25問の試験です。合格か不合格かも出ますし、各分野ごとの結果も出ます。
こちら、かなりおすすめです。
なぜかと言うと、試験ではどのような問題が出るかわかるため、どのような勉強をすれば良いかが理解できたからです。
例えば、試験では「EBSのプロビジョンドIOPS SSDのIOPSの最大値は？」みたいな一問一答な問題は出題されず、「AWSのクライアントはこのようなシステムを作りたいと思っています。これを実現するときにストレージとしてEBSを使うとき、どのオプションが良いでしょうか？」みたいな問題が出ます。
何が言いたいかというと、もちろん細かくIOPSやスループットを暗記することも大事なのですが、それによってサービス同士を比較できるようになることです。
もっというと、サービスやそのオプションごとのユースケースを暗記、理解した方が合格への近道となると感じました。
模擬試験は、この事実を自分に気づかせてくれたので非常に良かったです。
AWS blackbelt
以下のAWSの公式のサイトで、各サービスがAWSのスタッフによってパワポ形式でわかりやすくまとめられています。
上で紹介したAWS認定ソリューションアーキテクトの本より、情報量が多いため個人的には、本に書いてある全てのサービスについてはblackbeltで学習することをお勧めします。
また、white paperというさらに詳細なドキュメントもありますが、すべて英語で書いてある上で詳細すぎるので、今回は読みませんでした。
AWSは上のblackbeltのリンクを辿ればわかると思いますが、主要サービス以外に恐ろしいほどたくさんのサービスが存在します。一応、各サービスが何をしているかは理解した方が良いと思います。blackbeltを読み込む必要はないと思います。
しかし、今回自分が失敗したと思ったのはAmazon Kinesisについてblackbeltでしっかり読み込んでおけばという部分です。
Kinesisに関する問題が、けっこう詳細に出たのですが、あまりBlackbeltで詳細に学習していなかったため、けっこうわからない問題がありました。
本に出てくるサービス以外でblackbeltでしっかり学習した方がいいサービスは下記です。
ここらへんをしっかりユースケースと伴に学習できていると心配はないかと思います。
Lambdaは参考書には出てきませんが、絶対出題されるので押さえましょう。
さて、今回は以上となります。
ではまた！
NoSQLとは？～大量データに対応したデータベースたち～
どうもkoheiです。
スマブラが楽しみです。
今日は前回に引き続きデータベースの話を
前回は構造化されたデータを扱うリレーショナルデータベース（RDB）について、書きましたが、今回は非構造なデータを扱うNoSQLについて触れたいと思います。
データベースって？リレーショナルデータベースとは？という方はこちら
NoSQLの誕生
前回のおさらいになりますが、表形式になる構造化データに対しては、RDBMSを利用することで、データの検索は管理が容易になります。
一方、世の中の多くのデータが表形式にはなりません。
頑張って表形式に合わせようとしても、なかなか構造的にうまくいかないものが出てきます。
昨今の爆発的なデータ増に対して、こうした大量で、非構造なデータを高速に、かつ容易に扱えるかが課題になっています。
そこで登場したのがNotOnlySQL(NoSQL)です。
NoSQLの仕組みと種類
wikipediaでNoSQLを見てみます。
NoSQL（一般に "Not only SQL" と解釈される）とは、関係データベース管理システム (RDBMS) 以外のデータベース管理システムを指すおおまかな分類語である。
ここで触れられている通り、NoSQLというのは「これまでのRDBMSで使ってきたものとは違う方式でデータを管理するもの」を指す言葉です。
この曖昧な定義のため、NoSQLデータベースには様々な種類があり、それぞれ方式もバラバラです。よくあるタイプとしては下記の3点があげられます。
1. Key-Value型
NoSQLの考え方で最も使われているのがこのKey-Value型です。
文字通りKey- valueの組み合わせでデータを管理します。
シンプルなつくりなので高速なデータ読み書きが期待されます。
また、複数のサーバでデータを分散して配置して置いても、Key情報をどのサーバが持っているかを管理出来れば、Valueを探索できます。つまり、スケールアウト（複数台のサーバに情報持たせて処理を分散させる）ことが容易です。
一つのKeyに対して、複数のvalueを持たせるKey-Value型もあり、カラム指向型と呼ばれることもあるそうです。
Key-Value型NoSQLの例：
Redis
2009年にイタリアのSalvatore Sanfilippo氏が開発しオープンソースソフトウェア(OSS)として公開。Key-Value型でデータを管理し、データをメモリ上で保持するためデータの読み書き性能が非常に高い。
AWSで提供しているKey Value型のNoSQL。Key-value型のシンプルな構成を活かした、高速なデータ読み書きと、データ容量に応じたスケールアウトが特徴。
複数ノードにデータをコピーして保持するため、単一障害点（ここが故障すると全体に影響を及ぼすポイント）がない。
Apache HBase
HadoopのHDFS上に構築するOSSのNoSQLデータベース。
Googleの大規模分散処理基盤「BigTable」を基にしている。maserサーバでデータがどう保存されているかを管理し、Regionサーバでデータを保持するので、Regionを増やせば簡単にスケールアウト可能。
Hadoopってなに？という方はこちらも参考に
2. ドキュメント指向型
データをドキュメント（主にjson形式）で保持し、管理します。ドキュメントという塊でデータを管理するので、各データ項目を定義しなくてもいいのが特徴です。
ドキュメント指向型NoSQLの例：
mongoDB
mongoは「hu"mongo"us」が由来らしい。OSSのNoSQLでは圧倒的なマーケットシェアを誇る。RDBMSのようなデータ検索クエリが使えて、豊富な言語サポートが特徴。
3. グラフ型
データそのものより、データ間の関係に注力しているのがグラフ型です。RDBMSでは大規模で複雑なデータ群に対する探索、集計は不得意ですが、グラフ型ではそうしたデータに対する検索機能などで効果を発揮します。
グラフ型NoSQLの例：
neo4j
洗練されたUIでSQLライクな言語（Cypher）でデータ処理機能を利用できる。
まとめ
NoSQLデータベースについてまとめてみました。
今日取り上げたものの中にも、様々なデータベースソフトが誕生しており、今回あげたジャンルだけには収まらないものも多数あります。
いずれもデータの急増に伴い、大量のデータを、素早く、柔軟に取り扱いたい、という要望から生まれています。
しかし、これらのニーズを一つの方法ですべて網羅はできないので、それぞれ得意分野を持った特殊なソフトがNoSQLとして出てきているように感じます。
このため、何でもかんでもNoSQL最高！と思って使うのは危険です。
（NoSQL導入して失敗した記事もよく見ます。）
使いどころを誤ると、本来の性能が発揮できなくなるなど、使いどころの見極めが大事になります。その製品の特長が何で、どこで使うのがよいのかを考えながら、NoSQLに触れていきたいですね。
ではでは
EDRとは〜医者の診察にたとえて説明してみた〜
どうも、ITコンサルタントのShoheiです。
MacBook Air、でましたね。奇跡的に予約開始直後ぐらいにストアにアクセスできたので予約してたんですが、間違って日本語キーボード頼んじゃったり、ディスク容量で迷ったりしてたら、結局到着が一週間遅れになりました。
でも楽しみだ！今この記事を書いているMacは今朝早速メルカリに出しました。3.5万でかなり反応得られていますがブログ読者なら2.5万ぐらいでお譲りします！
さて、実は今日Databaseに関して書こうと思ってたのですが、綺麗サッパリ前日のKoheiの記事と被りました。
ということで今日は、前回の僕の記事の続き、エンドポイントセキュリティ、とりわけEDRについて書こうと思います。
EDRとは
"EDRとは"でググると、我も我もと、名だたるセキュリティ企業たちのWebページがヒットします。
もっとベンダ企業バイアスのない確固たる定義が欲しいなぁと探していたら、やはりガートナーさんに行き着きました。
After a long agonizing process that involved plenty of conversations with vendors, enterprises and other analysts, I have settled on this generic name for the tools primarily focused on detecting and investigating suspicious activities (and traces of such) other problems on hosts/endpoints: Endpoint Threat Detection & Response. ((https://blogs.gartner.com/anton-chuvakin/2013/07/26/named-endpoint-threat-detection-response/ (2013年7月記事)))
上記英語ですが、重要点を和訳すると、ホスト/エンドポイント上の疑わしいアクティビティ（およびそのような痕跡）を検出し、調査することに主に焦点を当てたツールという部分です。
そう、キーワードは、アクティビティです。少し細かく説明しましょう。
従来型エンドポイントセキュリティの場合
アクティビティ検知の話の前に、それを使わない従来型エンドポイントセキュリティのウイルス検知の仕組みを簡単にお話しします。たとえをあげましょう。
非ITのたとえで説明します
以下の絵は、医者が患者を診察するシーンを表しています。
患者は頭痛を訴えて医者のもとに来ています。
医者は患者に感染している細菌の情報を取得できており、それを元に診察をしているとします。
図の左側をご覧ください。患者に感染している細菌は、インフルエンザの菌です。
医者はインフルエンザの菌が悪性であることを知っているので「この患者は病気に感染している」と特定し、対処を始めるでしょう。
では、右側はどうでしょう。患者は明らかに頭痛を訴えて来院していますが、患者に感染している菌が未知の菌です。医学書にも登場していない菌なものなので、医者は診察の際、異常なしと返します。
IT用語を使います
IT用語でいうと、先ほどの医者が持っている悪性菌のリスト(医学書などをベースとしたもの)はシグニチャと呼ばれています。もう少し一般的にいうとこいつが悪いもの、というものを判断するための基準、といったものでしょうか。
従来型のアンチウイルスソフトでは、シグニチャを元に、PCに置かれたファイルがマルウェアかどうかを判断します。
従来型アンチウイルスソフトを意識してもう少しだけ正確に言います
上記の例は、医者がすでにかかってしまった病気を判定するシーンをあげました。
アンチウイルスソフトをいれていなかったPCにソフトをいれ、すでに感染していないかをチェックするためにファイル全体をスキャンする、という場合は今までの例でOKですが、実際のアンチウイルスソフトはウイルスにかかる前にウイルスを除外します。
この構図を絵に描くと以下のようになります。ちっさいおっさんが口や鼻の部分に待機しており、菌が体に入る前にこの善か悪か判定をし、悪性の菌を除外する構図になっています。
ただ、上述のようにこれはシグニチャベースなので、シグニチャが古かったりシグニチャにないものがくると対処は漏れます。
菌が入ってもすぐに気付けないので、最悪の場合、死に至るなど相当深刻な自体が見える化されるまで感染に気づかないかもしれません。
ITでいうと、情報が抜き取られても気づかない、その後PCが全てロックされて初めて気づく、といったところですかね。
EDRでできるアクティビティ検知
では、アクティビティ検知の話にいきましょう
非ITのたとえで説明します(検知方法)
絵をみたら明らかですかね。
上記のように菌が悪性かどうかという照らし合わせにより病気を判断するのではなく、状態や行動などから総合的に病気を判断しています。
これにより、未知の菌についても異常を見極め、対処に進めることができます。
実際のEDR製品等でいうと
図でいうと以下のイメージです。
同じく小さいおっさんが入っており、入ってくる菌の種類ではなくて体の状態を監視しています。
そうすることで知らない菌であっても、感染したらすぐに体の異常（喉の腫れなど）を検知し、なんらかの対処(実際のITの例でいうとファイル隔離や論理抜線など）にうつります。
発想がかわっている
さて、ここまででお気づきいただいたかもしれませんが、従来型アンチウイルスソフトとEDRでは発想が少し変わっています。前者の場合は、菌を体内にいれない、という防御の部分に特化していましたが、EDRは異なります。
防御よりむしろ、入った場合に素早く確実に検知をする、という発想に変化しています。
日々新たな攻撃手法が開発され、セキュリティ攻撃を100％防ぐことができるとは言えない時代になっているので、せめて感染したとしても検知と対処の時間を早めて被害を最小限に抑える、最後の砦的なものがEDRです。
まとめ
EDRについて説明しました。
AWSストレージまとめ
どうも、Keiです。
今日から完全に秋って感じの寒さですねー。
今回も前回、前々回に引き続きAWSについてスポットを当てています。
AWSのサービスにはストレージがたくさん登場しますが、カスタマーや業界の技術進化に合わせて本当にたくさんの種類のストレージが存在しています。
正直、自分が実現したいサービスはどのストレージを使えば良いのやら？って方も多いのではないかと思います。
特にAWSのサービスの中でもストレージの種類が多いので、今回ここでまとめたいと思います。
ストレージの種類
まずはざっとストレージの種類を見てみましょう。
（データベースもストレージとして列挙しています。）
- EBS
- インスタントストア
- S3
- Gracier
- EFS
- RDS
- Dynamo DB
- Redshift
- Neptune
一番有名なのは、オブジェクトストレージであるS3でしょうか？
簡単に説明を加えたいと思います。
- EBS
AWSが提供するブロックストレージ。主にEC2のブートボリュームに使用されます。 - インスタントストア
EC2のRAMで、揮発性のストレージです。EC2の再起動、削除によって内容が消えるため、計算の一時ファイルなど、EC2が故障やメンテナンスで再起動しても問題ないデータを格納します。 - S3
AWSが提供するオブジェクトストレージ。ボリュームの上限はありません。結果整合性によりリアルタイムの書き込みが即時反映されないので、主にアーカイブ用のデータや静的なwebホスティングストレージとして使用されます。 - Gracier
S3同様アーカイブとして使われることが多いですが、さらにアクセス頻度が低いデータを格納します。この理由として、GracierはS3と比較して料金が安いことと、その代償としてデータの要求をしてからデータにアクセスするまでに時間がかかることが挙げられます。データアクセスには3タイプあり、一番早い迅速（expedited）モードでは５分でアクセスできますが、大容量（Bulk）モードでは最大12時間程度かかってしまいます。 - EFS
AWSが提供するファイルストレージ。一般に私たちが使っているファイルストレージのクラウド版です。特徴として、数千という非常に多くのインスタンスからアクセスが可能であり、データも即時反映されるため、リアルタイムにファイルを読み書きしたい要望に最適です。 - RDS
ÅWSが提供するリレーショナルデータベースです。AWSが独自に開発したデータベースであるAmazon Auroraを始め、MySQL、SQL server、PostgreSQLなど有名なSQLを利用することができます。 - Dynamo DB
こちらではNoSQLを利用することができます。基本は結果整合性なためデータの即時反映はされませんが、「強い整合性」オプションを有効にすることにより、データの即時反映が可能となります。一方で、この代償としてスループットが半減してしまいます。AWSがおすすめしている使用方法は、「強い整合性」を有効しなくても要件を満たせる場合に使用することです。 - Redshift
データウェアハウスデータベースとして利用されます。ペタバイトの大容量のデータを格納できる。EFSのように同時アクセスは少ないが、一回のアクセスで複雑なSQL処理を行うような要望に適しています。 - Neptune
グラフデータベースサービスです。NoSQLに分類され、高速かつ6つのAZにリードレプリカ（複製）が保存される非常に高信頼なグラフデータベースです。
さらに詳しい分類があるストレージたち
さて、もう既にお腹がいっぱい感があるのですが、上記ストレージの中でもさらにオプションが複数分かれています。
今回はその中でも、よく使うということと、分類の多いS3とEBSについて紹介したいと思います。
S3の分類学
まず、ストレージのオプションが何故このように種類が多いかと言いますと、なるべく料金を安くするためです。
ストレージで重要となってくるのは、「最大容量」、「スループット（IOPS/ポート速度）」です。ここで、AWSはスケールアウト/インが自在なので「最大容量」は無限である場合が多いですが（事実S3は無制限にスケールアウト可能）、「スループット」は需要によって変動します。
そして、この「スループット」が料金にダイレクトに跳ね返ってくる部分なのです。
そのため、高い料金で高いスループットのストレージを契約しても、全然需要がなければ、オーバースペックとなり無駄となってしまいます。
この料金を最適化するために様々なパターンのストレージが存在するわけです。
さて、それではS3のオプションを見てみましょう。
- 標準
- Standard IA
- RRS
- Gracier
さっきGracierはS3と同列に紹介しましたが、GracierはS3の低価格サービスのようなものです。
標準S3は一般的なS3なので上で既に紹介しました、標準とGracier以外の説明をしますと
- Standard IA
標準S3は1G単位で月額の料金を支払う方式ですが、Standard IA（Infrequent Access）ではデータへのアクセスが低い場合に料金が安くなる可能性があります。データへのアクセスによって課が発生するため、アクセス数があまりない場合に最適な体系となります。 - RRS（Reduced Redundant Storage）
S3はSLAが99.999999999と非常に高い耐久性を示しますが、そこまで耐久性が必要ない場合はRRSを利用すると料金が安く済みます。RRSのSLAは99.99です。
EBSの分類学
次に、主にルートボリュームに使用されるEBSですが、こちらはスループットによって5つの分類に分かれます。
なんか本当に試験勉強みたいですよね笑
汎用SSDからMagneticへの順でIOPSが高い順に並んでいます。
また、料金もほぼほぼ高い順に並んでいます。
上2つはSSDで下3つはHDDをストレージデバイスとして使用します。
簡単にそれぞれのオプションのパラメータをまとめてみました。
- 汎用SSD
IOPS：最大32000IOPSスループット：128Mbps～160Mbps用途：大規模データベースや10000IOPS以上の書きこみを要する アプリケーション - Provisioned IOPS SSD
IOPS：100～10000IOPSスループット：最大500Mbps用途：OSのブートボリュームや、小中規模のデータベース、検証環境 - スループット最適化HDD
IOPS:500IOPSスループット：ベース40Mbps、バースト250Mbps、最大500Mbps 用途：EMR、DWH、ETL処理、ログ分析など - コールドHDD
IOPS：250IOPSスループット：ベース12Mbps、バースト80Mbps、最大250Mbps 用途：ログデータ保管、アーカイブ - Magnetic
IOPS：平均100IOPSスループット：40～90Mbps用途：アクセス頻度の低いデータ、コストを最重要視する場合
IOPSが下がるほど、アーカイブ系のユースケースが多くなっていますね。
スループットのバーストというのは、例えば、需要トラヒックが契約速度以下でランニングしていたときに、余った帯域をクレジットとしてプールしておき、瞬間的に多くのトラヒックが来た際に契約帯域以上の速度を出せるという仕組みです。これをバースト時の速度として、上にまとめています。
当然、バーストでも対応できないトラヒックに関しては最大スループット以内で速度を指定する必要がありますが、料金は当然高くなります。
さて、いかがでしたでしょうか？
AWSの資格であるSolution Architectを受ける方にとっては、いい感じにまとめることができたかと思います。
是非、種類の多さに圧倒されずユースケースと一緒に理解するようにしてください。
（という僕も絶賛勉強中です。。）
それではまた！
リレーショナルデータベースについてまとめてみた
どうも、koheiです。
さて今日はデータを扱ううえで欠かせない技術
「データベース」について書きたいと思います。
データベースとは何者なのか
さて、データベースって何者なんでしょうか
なんとなくデータを貯めてる箱？みたいなイメージがあります。
wikipedeia先生によると下記の通り
データベース（英: database, DB）とは、検索や蓄積が容易にできるよう整理された情報の集まり。 通常はコンピュータによって実現されたものを指すが、紙の住所録などをデータベースと呼ぶ場合もある。コンピュータを使用したデータベース・システムでは、データベース管理用のソフトウェアであるデータベース管理システムを使用する場合も多い。
つまり、データが扱いやすいようになっていれば、それはデータベースというようです。さてここでは、この説明の後半「データベース管理システム」に該当しますが、
データを扱いやすくするソフトウェアについて述べます。
データのカタチ
データベースについて説明する前には、データベースが扱うデータについて触れておかねばなりません。データにはどんな種類があるでしょうか
ざっと思い浮かべただけでも
テキストデータだったり、画像だったり、システムのログだったり、決済、売上値
などなど...
その形式や形も様々です。
データベース的な観点で言うと、以下の二つに分かれます。
- 構造化データ：いわゆる表形式になるデータ。構造が決まっている。
- 非構造化データ：表形式にならないデータ。規則性の有無はある。
こうしてみると世の中の大半は非構造なデータですね。 昔から、構造化データに対してはデータベースソフトウェアが広く利用されていました。そもそも「構造化データ」という言葉も、もともとデータベースソフトから生まれた言葉と言われています。
近年では、データ活用の発展に伴い非構造なデータを扱うデータベースシステムも登場してきました。
構造化データを扱うRDBMS
データを整理する方法として、よく考えるのは表形式にまとめることです。
この「表形式にデータをまとめて管理する」という考え方から生まれたのがRelational DataBase Management System（RDBMS/RDB）です。
なんか難しそうですが、要するに行と列の二次元表(relation)形式でデータを整理してる、ということです。
世の中の一般的にはデータベースと言えば、こちらを指すと思います。
RDBMSはただ表形式でデータを持つだけでなく、様々なmanagement機能を提供してくれます。
- SQLによる容易なデータアクセス
データベースのデータにアクセスする際にはSQL ( SEQUEL [Structured English Query Language] が由来らしい)という言語を使います。
データベース製品はたくさん出ていますが、SQLはISO(国際標準化機構)で規格化されているので、同じSQLで他のデータベース製品にも（ほぼ）同じように使えます。
- トランザクション管理
複数ユーザが同時にデータの参照・更新しても、データの不整合が起きないように管理します。ACIDというデータの整合性を担保する性質に基づいています。
- セキュリティ
データを表形式のテーブルやその集まりであるスキーマなどの単位で管理し、それぞれのアクセス制御を細かく設定できます。
他にも不正なデータ登録を防ぐための制約機能や、障害時の復旧管理など。。。
RDBMSには、データの管理・利用を容易にするための機能が兼ね備えられています。
RDBの例
さて、世の中のRDBMSについてまとめてみました。
オープンソースソフトウェア（OSS）では一番有名どころ。OSSのDBMSでは世界シェア8割以上と言われる。 2010年にoracleに買収されてから、商用利用は有料になったので、派生した純OSSであるMariaDBが注目。
オープンソースのデータベースソフト。MySQLに次ぐ有名どころ。比較的日本のシェア高め。MySQLとよく比較されるが、postgreSQLのほうが機能も豊富で標準SQLの準拠度が高いと言われるが、性能面はMySQLのほうが良いともいわれた。（最近は…？）
他のDB製品に比べて軽量で、アプリとして動作できるパブリックドメインのDBソフト。他のDBソフトに比べて機能が少なく、大規模なデータ処理には向かないが、組み込みシステムなどに利用される。
ORACLE DATABASE
世界初の商用RDBMSであり、企業向けデータベースソフトの最大手。最大手過ぎてもはや、データベースソフトのデファクトスタンダードになりつつある・・・が、最近は他のDB製品と競争が激化している。他のDB製品と比べて、システムやSQLが独特。最新のoracleは機械学習を活用した、全自動運用、チューニングされる世界初の自律型DBとして話題。
microsoftの提供する商用DB。商用DBMSでは、oracleと人気を二分する。
microsoft開発ともあって、windowsとの相性がよく、GUIツールが充実。oracleよりコストパフォーマンスに優れる。Transact SQLと言われる独特なSQLを使う。
IBMの提供する商用RDBMS。oracle, microsoftに次ぐシェアを持つ。2017年にDB2からDb2に名前が変わった。oracleと比較してコストパフォーマンスがよい。（…というかoracleが高い）メインフレーム（企業の基幹システムに使われるような大型コンピュータ）の時代から利用され、安定感のある歴史の長いDBMS。
SAP HANA
SAPが提供する企業向けRDBMS。 (「HANA」はデータベース以外にも周辺のアプリも含めたデータプラットフォームを指す) すべてのデータをメモリー上に保有し、高速処理するインメモリーデータベース処理が売り。とにかく速い。2011年にリリースされたばかりで分析用DBとして注目。
まとめ
さて、ここまでデータベースとは何者か、そして主だったリレーショナルデータベースソフトについてまとめてみました。
今日はまとめきれませんでしたが、次回は非構造化データを扱うNoSQLについても触れたいと思います。
ではでは
