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についても触れたいと思います。
ではでは
セキュリティ強化のためのサイバー・ハイジーン
どうも、ITコンサルタントのShoheiです。
ついに来週、アップルのスペシャルイベントきますね。今からわくわくです。
さて、今日はセキュリティ関連のトピックとして、IT資産管理/衛生管理について説明していきましょう。
ネットワークセキュリティとエンドポイントセキュリティ
セキュリティ対策は、下に示すように、通信経路で身を守るネットワークセキュリティと、狙われる情報などを扱うPCやサーバー側で身を守るエンドポイントセキュリティに大別されます。
ざっくりいうとネットワークセキュリティはFWやIPS/IDS、WAFなどをさし、エンドポイントセキュリティはEDR/EPP/資産管理などをさすと考えてください。
注目されるエンドポイントセキュリティ
従来は、どちらかというとエンドポイントセキュリティはオプション的なイメージで、ネットワークセキュリティ(とりわけ入口対策）の方が重視されがちな傾向にあったようです。上の図でいうと、しっかりした警備員を置いておけば大丈夫だろう、みたいな状況です。
しかし、昨今はエンドポイントセキュリティも注目されています。
ガートナーの"日本のセキュリティーリーダが取り組むべき重要アジェンダ6項目"*1 の中にも、がっつり"エンドポイントのセキュリティの最適解とは"という記載が書かれており、その他5項目にNWセキュリティの記述はありません。
また、同社の"2018年のセキュリティプロジェクトトップ10"*2のレポートの中にも、以下の記述があります。
セキュリティ侵害は不可避であるという認識に基づき、エンドポイント、ネットワーク、ユーザー・ベースのいずれかのアプローチによって高度な脅威の検知、調査、対応能力を実装したいと考えている企業向けのプロジェクトです。3つの選択肢があります。
・エンドポイント保護プラットフォーム (EPP) + エンドポイントの検知／対応 (EDR)
・ユーザー／エンティティ挙動分析 (UEBA)
・偽装テクノロジ (Deception)
ネットワーク、という言葉は出てきていますが、具体的に記述されているのはエンドポイントよりのことばかりです。
なんでエンドポイントセキュリティが注目されてるの？
もちろんネットワークセキュリティが不要、という認識はないですが、上述のようにエンドポイントセキュリティが今までよりも注目されているのは確かです。
この理由には以下があると考えられます。
- 働き方改革の一環としてのリモートワーク推進による、接続ネットワーク/使用デバイスの多様化
- 攻撃の高度化/多経路化によるNWセキュリティ側での対処漏れの増加
- 暗号化通信の増加など、レガシーNWセキュリティで検知できない通信の増加
これら理由により、今までのようなレガシーなNWセキュリティのみでは対応できなくなっており、最後の砦であるエンドポイントセキュリティ対策が注目されるに至っていると考えます。
IT資産管理の重要性
では、IT資産管理/衛生管理の話に入ります。
衛生管理(サイバー・ハイジーン)とは何かというと、以下の2つを実行することです。IT資産管理だけだと前者のみを示すことが多いイメージですが、広義では衛生管理と同義だと思っています。
- 守るべき情報にアクセスする機器を明らかにすること (仕事に使うPCなどを全部明らかにすること)
- 守る情報にアクセスする機器の、衛生状態を保つこと(脆弱でないバージョンのパッチがOSにあてる、ソフトウェアのバージョンを新しく保つなど)
つまり、大事な情報にアクセスする機器は、ちゃんとソフトウェアのバージョンとかもアップデートするようにして、攻撃されないように保てよ、ということです。
ささいなことですが、重要です。これがどれくらい重要かというと、以下の記述*3 をみれば明らかでしょう。
2018年から猛威を振るう「WannaCry」に代表されるランサムウェアは、しばしば「身代金を要求する悪意あるソフトウェア」と表現される。感染するとPC内のデータを暗号化し、「元に戻してほしければ指定の額を支払え」と要求する手口が特徴だ。特にWannaCryは、Windows OSの脆弱性を突いて拡散するワーム型だったことから一気に感染を広げ、国内外の多くの企業が被害を受けた。
米ベライゾンの調査「DBIR」2015年度版は、「悪用された脆弱性の99.9％は公表後1年以上経過したもの」だと指摘している。手元のIT資産を適切に管理して、既知の脆弱性をつぶしておけば、ゼロデイ対策に右往左往しなくても大半の侵害を防ぐことができるという指摘だ。
セキュリティ攻撃界隈は、 かなり動きが早く、高度な技術を持ち合わせています。
上述のように、ソフトウェアなどの脆弱性が発表されたにも関わらず放置していると、すぐに狙い目判定されてしまい、攻撃の対象となってしまいます。
スマートなIT資産管理を
よし、衛生管理するぞ！となっても、以下のようなレガシー管理をやっているようでは、意味ないですよね。
稼働もかかるし、リアルタイム性も失われますし、集まった情報の信憑性も保証されません。
そこで重要となるのが資産管理ツールです。
製品によりますが、エージェントなどをインストールすることで、自動的に情報蒐集します。端末から直接送られるデータなどの、基本的には嘘のない信ぴょう性の高いデータとなります。
さらに、バージョンが古いものを見つけたらバージョンアップを適用したり、社内システムなどとのアクセスを制限することができます。
「でもそもそもエージェントいれる対象として申し出のなかったPCはエージェントいれれないから管理できないよね」といういい質問に対しては、例えば社内NWに接続している端末を自動検出し、エージェントを強制インストールするなどの機能を備えた製品もあるので、それを使えば解決できます。
まとめ
エンドポイントセキュリティの重要性と、IT資産管理/衛生管理について説明しました。
*1:EZニュース, https://enterprisezine.jp/article/detail/11013 ,2018/7/25
*2:Smarter with Gartner, https://www.gartner.co.jp/press/pdf/pr20180710-01.pdf, 2018/7/10
*3:端末の「衛生管理」から始めよう――ハイジーンが実現する企業のレジリエンス：ゼロデイ対策や新ソリューションで右往左往する前に - ＠IT
【AWS】構成図作成サービスCloud Craftを使ってみた！
どうも、Keiです。
最近体を動かしていないので、ボルダリングとかやりたいです。
さて、今回は前回に引き続きAWS関連の話をしていきたいと思います。
AWSとは何か？だったり、どのような構成があるの？という場合は是非前回の記事を見て下さいね！
前回の記事のように、AWSでシステムを組む際に構成図をパワポなどで作ると全体像がすぐわかって便利ですよね。
一方で、もう既にAWSのサービスを使っていて大規模なシステムを組んでいる場合は1から図を作るのも面倒なものです。
構成可視化をサポートするサービス
実は2018年10月現在、この悩みを解決する以下の3つのサービスが存在します。
- Amazon Cloud Formationデザイナー
AWS公式が出しているサービスです。Cloud FormationというAmazonのインフラサービスの構成、デプロイをコード化して自動化するサービスの付加機能で現在稼働中のAWS環境を図示してくれる便利なサービスです。
こういう痒いところに手が的なサービスを公式で出しちゃうのが、AWSの魅力ですね。
- Cloud Craft
こちらは3rd partyが出しているAWSの機能を3Dに可視化できる機能です。今回の記事ではこちらを取り上げます。
AWSから構成をインポートして、自動的に図を作り上げる機能もあります。
- Hava
こちらもCloud Craft同様、3rd partyのサービスです。
Cloud Craftは3Dで表示していましたが、こちらは2Dで表示しており、AWS公式の描画に近い印象です。AWSから構成のインポート、自動生成もサポートしています。
Cloud Craftを使ってみよう
今回はCloud Craftを使って、前回の記事で例題として挙げた図を作成してみます。
何故、Cloud Craftを選んだかというと、誰が作ってもかっこよく、そしてセンスよく仕上がるからです笑
いきなり結論ですが、Cloud Craftを使って作成した図がこちらとなります。
どうですか？
けっこうかっこよくないですか？笑
前回パワポで作った図も再掲して比較してみます。
今回、ルートテーブル等は作成していませんが、かなり見やすい図ができたかと思います。
しかもこれがわりと簡単にできちゃうっていう。
クライアントに綺麗な図を見せたいなんていう、クラウドアーキテクトの要望にもしっかり応えてくれる機能だと思います。
しかも、パワポより簡単に早くアイコンやゾーン、VPCの設置ができるのでオススメです。
使ってみての感想
- ライブラリに綺麗な作成例があり、それを使うことができる
- 四角形や三角形などの多角形を頂点の数を編集することで自由に表現できる。これによって複雑な図形も描ける。photoshopでいうパスみたいな感じ。（ベジェ曲線はさすがに表現できません笑）
- 無料だとグリッド（アイコンを置く範囲）が有限なのでけっこう狭い
- Ctl＋マウスで選択範囲を指定する際に、斜めの角度で選択するので最初は感覚的に難しい
なかなか使い勝手の良いツールでした。
無料版だけだと、複雑なシステムは描けないかと思うので本格的に業務で使うという方は有料で使用してみてはいかがでしょうか？
月49USドルで使用できるみたいですね。毎日使わないと若干高いか・・・？
今回はCloud CraftというサービスでAWSサービスの構成の可視化について紹介しました。
個人的にはなんでも斜め45度にしたらかっこよくなるんじゃね？と感じさせられたサービスでした笑
それではまた次回！
