セキュリティ強化のためのサイバー・ハイジーン
どうも、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度にしたらかっこよくなるんじゃね？と感じさせられたサービスでした笑
それではまた次回！
Gartnerのハイプサイクルから見るIT新技術のトレンド～ビッグデータの流行りは終わった～
どうもkoheiです。
秋も深まってきました。
先週、IT調査会社のgartner japanが日本におけるテクノロジのハイプサイクル2018年が発表されました。
今回はこの記事を基に、IT業界の流行りについてみていきたいと思います。
ハイプ・サイクルって？
wikipediaにのってました。
ハイプ・サイクル（英語: hype cycle、ハイプ曲線）は、特定の技術の成熟度、採用度、社会への適用度を示す図である。ガートナー社がこの用語を造り出した[1]。
あんまり聞いたことないなって思ってましたが、それもそのはず、ガートナーが生み出した言葉でした。
ハイプサイクルは次の5角段階から構成されるそうです。
黎明期（技術の引き金、Innovation Trigger）
流行期（過剰期待の頂、Peak of Inflated Expectations）
幻滅期（幻滅のくぼ地、Trough of Disillusionment）
回復期（啓蒙の坂、Slope of Enlightenment）
安定期（生産性の台地、Plateau of Productivity）
このハイプサイクルを通すことで、世間的に期待の集まっている新技術をピックアップしたり、幻滅期に入り世間的にしぼんでいく技術がどれなのかを確認することができます。
「うちの会社で最近○○について導入を検討してみたけど、もう幻滅期やんけ！トレンド遅れてる！」
とか、
「お、最近聞いたあの会社、これから期待できる技術もってるな。もう少し話聞いてみるか」
とかいう判断基準になるわけですね。
もともとガートナーがこれを作り出したのも企業が最新技術を取り入れるべきか否かの判断材料の一つとして利用するためだと言われています。
ただ一点注意ですが、もちろん幻滅期に入ったら技術的にオワコンというわけではないです。幻滅期、回復期のものこそ、技術的に安定しつつあるものという捉え方もできます。まあ、そもそもガートナーが勝手に決めてることなので一つの参考情報程度です。
ただ調査を仕事にしているだけあって、それなりによく調べられてるんじゃないかなぁと思います。
ではさっそく、ハイプサイクルについてみてみましょう。
ガートナー社のニュースリリースより、ハイプサイクルの図を引用しています。
ビッグデータで盛り上がる時代は終わった
さて、このハイプサイクルですが、最初に目をつくのはやはり「ビッグデータ」が「安定期に入る前に陳腐化」とされている点です。
ここでいう「陳腐化」というのは、技術的に陳腐化していくというより、世間や企業の期待や関心の高さを示しています。
確かに、最近ニュースとかでも「ビッグデータ」って聞かなくなりましたね。単なる「データ」とかいう方が多い気がします。
おそらく、いわゆる「ビッグデータ」が当たり前になってそのデータを使って何をすべきか？という点に関心が向いているからだと思います。
そのほか、「人工知能」や「ブロックチェーン」についても、期待のピークを越え「幻滅期」に入ろうとしており、バズワード的な流行りから、具体的な利用検討にシフトしている様子も伺えます。
次に期待されるテクノロジー
細かいものがいろいろありますが、個人的な気になるポイントをピックアップ
1. IoTプラットフォーム/IoTセキュリティ
幻滅期に入っているIoTとは別に、これから期待として高まっているのがIoTプラットフォーム＆セキュリティです。これはIoTが広まるときから懸念されていたポイントで、あらゆるモノがネットワークとつながった先に、それをどう制御して活用すべきか？かつ安全に扱うべきか？という課題が高まっているという事実を示しています。
IoTプラットフォームについては、IT業界だけでなく製造業からも開発提供する企業が出ており、今後競争がさらに激化していくことが予想されます。
2. 市民データサイエンス
これぱっと何かわからなかったんですが、、、調べてみました。
そこで見つけたのが、やはりGartnerの記事
Gartner defines a citizen data scientist as a person who creates or generates models that use advanced diagnostic analytics or predictive and prescriptive capabilities, but whose primary job function is outside the field of statistics and analytics.
これによると、市民データサイエンティストは、本業データサイエンティストじゃないけど、データ分析スキルを持つ人のことをいいます。
つまり、専門家でなくても一般的な人々がデータ活用ができるような環境が実現されることを言っているんですね。「データの民主化」と呼ばれるキーワードもあるように、誰もがデータを活用していく時代になっていく…ということですね。
3. AIOps
AIOpsの正式名称はAlgorithmic IT OperastionsともArtificial Intelligence for IT Operationsともいわれてます。これもGartnerが生み出した言葉のようです。
ちょっと前までのDevOps(開発と運用を一体化してソフトウェア開発を行う)に近いように感じますが、もう少しIT運用目線が濃くなっているように思います。
AIOpsの目指すものは、データに基づいてAIを使って人手を最小限にしたIT運用を実現することです。
例えば、自動的にリソースを監視してシステムの異常検知を行ったり、その結果に基づいて故障回復処理を自動的に行ったり、あるいは測定値に基づいてリソース制御を行ったり・・・というのを一元的に実現することが想定されます。
こうして例を挙げてみると、一つ一つは今までの自動化技術に思えますが、さらに踏み込んで人間の判断を機械に任せる部分にも入り込もうとしているんじゃないかなぁと思います。
AIOpsを実現するソリューションを提供する企業もいくつか出てきているようです。
OpsRamp
SaaSベースのIT運用管理プラットフォーム。AWS, Azure, GCPといったマルチクラウドに対応して、アラートやイベントの推論もAIを使って実現しているそうです。
Moogsott
機械学習をベースとしたSaaSソフトで、企業向けにマネジメントソリューションを提供しています。CiscoやYahooでも利用実績があるとか
まとめ
さて、今回はGartnerのハイプサイクルを基に、IT技術の期待やトレンドを追ってみました。まだまだ知らない技術もたくさんありますが、引き続き、特に新技術については、まだまだトレンドを追っていく必要がありそうです。
ではでは
One life, One password その１
どうもhaseです。
今年日本国内進出を果たしたOPPOが、先日フラッグシップモデルFind Xの発売を発表しました。このスマホ、面白いのがインカメがスマホ前面になく、顔認証・撮影等するときにシュッと上部から飛び出してくるんです。それによって驚異の画面占有率93.8%(iPhone Xs Maxで84.4%)という、真の全画面スマホを実現しています。
早速ベンチマークブーストの話も出てきちゃってますし、こういうギミック系が定着するイメージもあまりないんですが、単純に面白いなあ、と。発売は11月上旬以降で、価格は税抜11万1880円とのこと。皆さんいかがでしょうか。持っていれば合コンのネタくらいにはなるかもしれません。
さて、前振りが長くなってしまいました…。
長かった割にまさかの1ミリも関係ないんですが(笑)、今日は認証の話をします。
SSO
どんどん増えるウェブサービス、社内システム。
あれ、このサイトのパスワードなんだっけ…って思ったこと１度や２度じゃないですよね。だからパスワードは紙にメモってる！とかデスクトップにメモって保存してる！って人いるんじゃないでしょうか。それ、だいぶ危険です。
一つのID/PWで全てのサービスに安全にログインできたら…。
これを実現するのがSSO（= Single Sign On）です。
今日はこのSSOの概要・メリット/デメリットについて述べていきたいと思います。
SSOとは？
繰り返しになりますが、一つのIDとパスワードを入力して、複数のWebサービスやアプリケーションにログインする仕組みです。入力や管理の手間を省き、セキュリティを強化することができます。
最近何かのサイトにユーザ登録する際に、Facebookでログイン、とか出てきませんか？あれです。
あとは社内にSSOを導入している企業であれば、社給パソコンにログインするIDで社内の勤怠管理システムだとか、発注システムなんかにも入れるんじゃないでしょうか。
これらがSSOと呼ばれる仕組みです。
SSOのメリット/デメリット
- メリット
何と言っても一つのID/PWでログインできるというところに尽きますが、それによる副次効果もたくさんあります。
まず、セキュリティ面。
IPAによる不正アクセス調査によると、不正アクセスの手口として最も多いのが利用権者のパスワードの設定・管理の甘さにつけ込んだもの（35.3%）です。
2015年不正アクセス統計・パスワードの不備が大きな原因に｜大塚商会
例えば、上記のように紙にメモしておいたり、デスクトップに保存しておく人結構いるかと思いますが、メモをなくしたり、机の上に開いていたり、デスクトップにロックをかけずに席を立てば、簡単にパスワードが流出します。でもID/PWが一つだったら？さすがの僕でも覚えられます。例えばパソコンのログインパスワードをメモってる人ってあまりいないですよね。それを他のサービスにも使えれば、メモっておく必要はないです。
また、複数のパスワードを設定しようとすると、結局同じパスワードを設定していたり、覚えやすいものを使ったりしませんか？これはブルートフォース攻撃（総当たり攻撃）による侵入を容易にします。それぞれのサイトにパスワードを設定する場合、パスワードが一つバレても他は大丈夫と思われがちですが、 使い回しやちょっと数字を変えただけだと簡単に侵入できてしまいます。
また、認証情報を管理する側からもメリットがあります。一元管理されていることによって、そこだけ本気で守ればいいですし、ユーザの新規登録/削除、パスワードの再設定作業なども楽チンです。 - デメリット
便利さの裏返しですが、パスワードが一つばれると、全てのサービスに入られてしまいます。また、統合認証基盤が落ちてしまうと、どのサービスにも入れなくなってしまいます。ユーザに対するセキュリティ教育や、パスワードの定期的な変更、統合認証基盤の冗長化などで対応していく必要があります。
SSOの大きな二つの流れ
SSOを実現する仕組みはいくつかありますが、個人的には大きく２つの流れがあると思っています。
- BtoB系
これは企業内の業務システムにおいて発達してきたSSOです。先ほどの例でいうと、社給パソコンへのログインID/PWで、勤怠管理等社内システムへのログインを可能にするタイプです。
基本的にはオンプレ想定の方式が多いですが、SAMLという標準プロトコルを使用すると、クラウドサービスなどとのSSOも実現可能です。 - BtoC系
こちらはFacebookでログイン、のタイプです。ソーシャルログインとも呼ばれます。Twitter社のブレイン・クック氏をはじめとした開発者が集って開発したOAuthなんかが有名ですが、初めからウェブサービス同士を連携させるという思想のもとに設計されてます。OAuthは正確には認証はしていないのですが、SSOと言って問題ないでしょう。
それぞれの具体的な仕組みについては、次回以降説明していきたいなと思ってます。
まとめ
複数のウェブサービスを利用するのが当たり前になっている現在、SSOはとても便利な仕組みだと思います。最近は冒頭のFindXのように（無理やり繋げました）顔認証などの生体認証が流行りですが、オンラインに生体情報を載せるのは僕はまだちょっと抵抗がある。生体情報って流出しても変えられませんしね。
ビル・ゲイツは2004年に"The password is dead"と宣言したそうですが、14年経った今でもバリバリの現役です。パスワードは完璧ではないですが、やっぱり使いやすいですからね。この傾向はまだしばらくは続くでしょう。SSOを利用して、もっと便利に安全にサービスを利用する仕組みが整えばいいなと思います。
では今回はこの辺で。
論理を武器にしよう〜ロジカルシンキング実践
どうも、ITコンサルタントのShoheiです。
Googleのスマホ、Pixel 3が最近すごく気になっています。
さて、今日は前回の続編として、ロジカルシンキングの実践編に入っていきましょう。
これまでのおさらい
前回記事では、ビジネスにおけるメッセージについてお話ししました。
"課題"・"答え"・"相手に期待する反応"からコミュニケーションがなり、さらに答えは"結論"・"根拠"・("方法)")からなることを説明しました。
何故あなたのメッセージは響かないのか (ロジカルシンキング/ビジネスコミュニケーション) - IT社員3人組によるリレーブログ
また、いくつか前の記事では、MECEについて解説をしています。
重複なく、漏れなく、ずれなく、を実現するためのアプローチ手法ですね。
本質理解とMECEアプローチ (ロジカルシンキング入門) - IT社員3人組によるリレーブログ
今回のお話
今回は、"課題"に対する"答え"を論理的に導くための手法について説明します。
なお、前回同様ですがここでの解説は以下の本から得た知識を元に記載しています。
当たり前ですがこの本で書かれていること全てを書くことはできませんし、すっ飛ばしている部分も多くあります。
ここでの話はロジカルシンキングを考える上でのとっかかりとして利用し、より詳細な理解には、この本や他の本をご自身で読んで理解し、練習を重ねることをお勧めします。
論理の基本構造
まずは、論理構造の基本について説明します。以下をご覧ください。(図は本を元に作成)
いきなりなんのことだ?という状態かと思いますので、上から説明しつつ、ポイントをあげていきます。
ポイント①
まずは課題に対応した結論を書きます。一番上の矢印のことですね。
「修学旅行でどこにいくべきか」という課題に対して、「京都にいくべきです」と答えること。「修学旅行は怪我等に備え保険に入っていることが重要である」という見当違いのものではアウトです。
ポイント②
答えである「京都にいくべきです」に対して、"Why So?(なんでそうなん)"と聞かれた時の答え要素が、下矢印の先、A,B,Cに記載されています。具体例は後ほどだしますが、その理由だったり、考察に用いた要素がABCに記載されます。
逆にABCから答えに戻る上矢印は、"So What(だからなんやねん)"という関係になっている必要があります。
ポイント③
"Why so?"で展開される要素たち(ここだとABC)は、MECEの関係にしてやりましょう。
これも後ほど具体例で解説します。
補足
- Aをさらに掘り下げる場合、Aに対してもう一度Why Soを考え、a-1,a-2,a-3を出します。答えをレベル1、ABCをレベル2とすると、a-1...はレベル3と呼ばれます(レベルは、難易度ではなく、階層を示すレベルです)
- ABCと記載していますが、要素は3つでなくてもいいです。
- 階層数に決まりはありません
論理パターン
基本の論理構造は上述の通りです。実際には、論理は二つのパターンに分けられます。
読者は「この基本構造で、本当にすべてのケースに対応できるのか？」と考えるかもしれない。答えはイエス。ただし、実際に論理構成する時には、２つの論理の基本パターンがあり、それを使い分けたり、組み合わせたりする。基本パターンは、「並列型」「解説型」の２つだ。
以下、一つずつ解説していきましょう。
並列型論理パターン
これは、先ほどの図の通りです。(図は本を元に作成)
やり方としては、課題が与えられて、MECEアプローチでABCを考え、結論を導き出す、といったところです。
例を書きましょう(課題・結論・考察要素は全て本を参照して作成。簡易化のため少しだけ言葉を簡易にかえています)。
MECEの4Cフレームワークを使って、４つの観点から不良品問題による影響を分析しています。その結果、記載の結論に至っています。
4Cで事態を多面的に考察していくあたり、The MECEて感じですね。
この例では難しいですが、他のフレームワークとして、4P(Product/Price/Place/Promotion)や、都市部/地方、質/量、事実/判断なども、有名なMECEフレームワークです。
解説型論理パターン
続いて、解説型。以下をご覧ください。(図は本を元に作成)
え、事実・判断基準・判断内容、これMECEなの？って僕も思ってましたが、上に記載したように、「事実/判断」はMECEアプローチになります。客観的事実とそれ以外、という排他的分け方ですね。判断基準も含めちゃうのは厳密なMECEかというとちょっと怪しいですが。
事実から判断を導く、という流れがあるので、この場合は矢印がついてフローっぽくなっています。
例をあげましょう(課題と、事実から判断に向けた考察の進め方部分は本と同じやり方を使っています)
プレゼン等のときにこの図を話すかどうかは別問題ですが、思考のプロセスの中でこういう構造を思い浮かべると、なかなかクールに考察できますね。
まとめ
超ざっくりですが、論理の型について説明しました。
個人的には、本でこの理論を知った時は目から鱗で面白かったです(特に解説型)。
より詳細に理解を深めたい方は以下の本をお勧めします。
【AWS入門】例題で実践学習！！
どうも、Keiです。
突然ですが、皆さんはAmazonを使っていますか？
使っていますよね？
毎日荷物が届いているって人もいると思います。
今日はそんなAmazonのサービスの中でも近年ありえないスピードで成長しているAmazon Web Service（AWS）について学習していきましょう。
AWSはご存知の方が多いかと思いますが、Amazonが提供しているクラウドサービスです。
2017年と比較した2018年の売上高は脅威の48%増だそうです。
また、少しデータは古いですがAWSで提供しているサービス数も毎年恐ろしい勢いで増加を続けています。
また、去年のガートナーのクラウドインフラストラクチャーの評価ではMicrosoftのAzureとGoogleのGCPを大きく離し、リーダーのポジションを獲得しています。
さて、このように快進撃を続けるAWSですが、皆さんの企業でも既に利用しているかと思います。
一方で、まだ利用していないという方も今後社内のITインフラをAWSに移行する機会があるかと思います。そんな時にAWSの知識は是非知っておいて損はない知識かと思います。
操作も、環境構成だけであればブラウザでポチポチ作るだけだし。
環境を作ってみよう！
今回は下のような基本的な環境を構築するときに、AWSでどう実現するかについて話をしたいと思います。
やはり、こういう技術的な話は本だけ読んでいても良くわからない部分があるので実際に手を動かしてみるのが非常に大事だと思います。
作成インフラ要件
今回は例題みたいな形で下のような環境を作ることを考えましょう。
細かい話はたくさんあるかと思いますが、まずはざっくりで！
【サーバ要件】
- EC2インスタンス x 3（Not dedicated）
- 各EC2インスタンスはAZ冗長
- 2台はWebサーバでELBで50:50にローバラ
- 残りの1台は基盤サーバとし、RDSとしてAmazon Auroraを配置
- EC2のストレージはEBS（ローバラ時IOPS 10,000未満を想定）
【ネットワーク要件】
- VPC[10.0.0.0/16]配下に/24の3つのサブネットを作成
- 3つのサブネットの内、2つをウェブサーバに使用し、インターネットからのアクセスOK
- 基盤サーバはプライベートネットワークとするが、バッチのDL等のために内側からのみインターネットにアクセスOKとする
【ストレージ】
- 各EBSのスナップショットを5分に1回S3ストレージで取得
【セキュリティ】
- S3へのEC2からのアクセスはIAMロールで行う
- ELBへの外部からのアクセスはHTTP/HTTPSのみとし、セキュリティグループにより実現する
AWSのサービスで実現すると
下記のような構成が考えられるかと思います。
簡単に各コンポーネントについて説明したいと思います。
EC2
皆さんもよくご存知の仮想サーバです。
今回は AZは3つ用意し、分散冗長させています。AMIやら細かい設定は今回は省略します。
EBS
EC2にアタッチできるブロックストレージ（従来からのHDDやSDDのようにディレクトリ構造のストレージ）はEBSとインスタンスストアがありますが、今回は不揮発性のEBSを使います。
基盤サーバのRDSとしてEC2にアタッチします。
ELB
ロードバランシングには各EC2をアタッチします。
S3バケット
オブジェクストレージとして、各EBSのスナップショット（バックアップ）を保存します。
各VPCやルートテーブルについても、ネットワーク要件に合わせて作成できているかと思います。
また、セキュリティグループやIAMユーザ/ロールについても図には起こしていませんが、適切に設定する必要があります。
次回はこれらの設定を含めてAWSのダッシュボード上でどのように入力していくかについて紹介したいと思います。
今回は、まずAWSのサービスを使ってどのように要件を具体化するかについて説明していきました。
それではまた！
データ分析を効率的に進めるためのプロセスとは～EDAを意識した分析～
どうもKoheiです。
最近のHUNTER×HUNTER、いつにもましてルールが多すぎて難しくないですか
さて、以前の記事で、データサイエンティストの仕事のプロセスについては下記のとおりになっていると書きました。
- 要件のヒアリング
- 必要なデータの収集
- 分析の準備
- データ分析
- 結果のアウトプット
今回はこのうち、4のデータ分析のプロセスについて、もう少し詳細に書きたいと思います。
過去の記事はこちらで
どんな分析をすべきか？
さて、分析してほしいデータを手に入れたあなた
まずは何をしましょうか？
そのままデータを読み込んでみようと思いましたが、データが大きすぎてすべては読み込めません。。。適当に数件ピックアップしてみてみます。
中には、数十以上のカラムで構成され、様々な数値や項目が入っています。
んーとりあえず、これを集計してみるか？
何をキーに集計してみようか…？データをもらった人にもう一度聞いてみるか…？
など、意外といろんな選択肢が出てきます。
「データを分析する」という言葉が示す範囲は非常に広いです。
こうした中、あらゆる問題を解決する
最強の方法！というものはなく、
具体的に分析する方法や手順はいくつかありますが、
自分が体験的にもこうした方がいいなぁ、と思ったものを紹介します。
データ分析のプロセス
このプロセスは下記の文献*1を基にしていています。
*1 "Doing Data Science", Cathy O'Neil and Rachel Schutt, 2013
分析する前のそのままのデータ（raw data）をまずデータ加工（Data processing）し分析するのに扱いやすいデータ（Clean Data）にします。
イメージはテキストでベタ書きされてるものをきちっと表形式に直すようなイメージです。
そこからそのまま可視化（visualization）して、レポートとしてすぐに利用するケースもあれば、合計、最大、平均値などさまざまな尺度からデータを探索的に調査し（Exploratory data anaylsis）、機械学習、統計モデル生成（machine learning/Algotichms）から予測や分類などを評価、AIとして利用するアウトプットも想定されます。
ここで注目すべきは探索的データ分析から再びデータ加工へ戻っているフローもあることです。データを探索的に繰り返し調査していくことで、データの本質を把握し、より効果的な統計モデルの生成などに繋げることができます。
さて、この「探索的データ分析」についてもう少し掘り下げたいと思います。
EDA(探索的データ分析)
探索的データ分析（よく先頭のキーワードをとってEDAと訳されます）は、1977年（！）にJohn W. Tukeyさんによって提唱されていた方法です。
簡単に言えば、「予想した仮説だけじゃなくて、データをいろんな側面で見てみようよ」っていう考え方です。
データが膨大な量になる今、全量を把握することはほぼ不可能で、データの担当者がなんとなくこうだろうと思っていても、実際データを見てみると別の意外な発見があった・・・なんてことも珍しくありません。
EDAを通じて、どんな変数が特徴を持つのか、外れ値や異常値の有無、適切なモデル・可視化方法の評価を進めます。EDAの具体的なアプローチは下記のとおりです。
1. 基本的な統計量の把握
- 平均、分散、最大値、最小値、中央値、四分位数などの算出
- 箱ひげ図などによる可視化
2. 単純データの可視化
- 各説明変数と目的変数の関係性の可視化
- 散布図、ヒストグラフなどでデータ全体の分布を把握
- 変数同士の相関関係の把握
- 外れ値、異常値の把握
3. 変数変換後のデータ可視化
- 主成分分析(PCA)などによる多次元データの次元削減。
- 対数変換、逆数などの変数の見せ方を変える
こうした方法を重ねて、データの本質を見抜いていきます。
EDAの際の注意点としては、EDAの時点ではまだ外れ値や欠損値が混在している可能性があるため、そうした外れ値に影響を受けにくい頑健な方法をとる必要があります。
平均値などは特に、一個のとびぬけた値に影響を受けやすいので扱いは気を付ける必要があります。
まとめ
さて、今回はデータ分析のプロセスについて書きました。
このEDAのアプローチは、データ分析コンテストのkaggleでもよく見られる方法です。
分析目的は様々ですが、実際にに上記のようなプロセスを意識して進めてみると効果的で効率的な分析が進められるケースが多々あると思いますので、ぜひ意識してみてはいかがでしょうか
ではでは
