Tomo's IT Blog

技術的な調査メモ

AWS: 特定のIPアドレスからしかアクセスできないIAMユーザを作成してみる

AWSのセキュリティの基本として、普段の運用管理は適切なロールを付与したIAMユーザにより実施して、ルートアカウントでは実施しないことが推奨されています。
特定のIAMユーザでAWSにログインする際に、例えば会社や自宅のIPアドレスからしかアクセス出来ないように設定しておけば、よりセキュリティの向上が見込めます。

ということで、今回はIAMユーザが特定のIPアドレスからしかアクセス出来ないように制御するための方法を調べてみたいと思います。

まずはIAMユーザを作成する

AWSコンソールで、IAM>ユーザ>ユーザを追加でユーザを追加します。
アクセス権限はあとでIPアドレスで制御が効いていることを確認することができればなんでもいいです。
例えば、SystemAdminなどを追加しておきます。また、AWSコンソールへのアクセスできるようにチェックしておきます。

ここで作成したIAMユーザで、AWSコンソールにログインしてIAMサービスにアクセスできることを確認しておきます。

特定IPのみからしかアクセスできないポリシーを作成

以下に色々なポリシーの例が載っていますので、こちらを参考にして作成してみましょう。

docs.aws.amazon.com

ここに、IPアドレスを制限する例が載っています。

"承認された IP アドレスまたは範囲以外からのブロックリクエスト"

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Deny",
    "Action": "*",
    "Resource": "*",
    "Condition": {"NotIpAddress": {"aws:SourceIp": [
      "192.0.2.0/24",
      "203.0.113.0/24"
    ]}}
  }
}

これを使って、IPアドレスを制限するポリシーを作成します。
まずは、ルートアカウントでAWSコンソールにログインして、IAM>ポリシーから新規にポリシーを作成します。
例えば、RestrectedIPなどのポリシー名で、上記の内容をそのまま設定します。IPアドレス部分はまずはそのままにしておいて、ちゃんと制限がかかりエラーとなることをまずは確認します。

IP制限ポリシーをユーザにアタッチ

IAM>ユーザで先ほど作成したユーザを選択して"アクセス権限の追加"でRestrectedIPポリシーを追加します。
その後に、AWSコンソールでIAMユーザでログインして、IAMサービスにアクセスしてみて下さい。

先ほどと違って、以下のようなエラーが表示されます。

リクエストの処理中に次のエラーが発生しました:
User: arn:aws:iam::027687984837:user/tomo is not authorized to perform: iam:GetAccountSummary
User: arn:aws:iam::027687984837:user/tomo is not authorized to perform: iam:ListAccountAliases

自分のIPアドレスをセットしてアクセスが出来ることを確認する

自分のインターネット向けのIPアドレスを確認するには、以下のURLにアクセスします。

http://checkip.amazonaws.com/

ここで表示されたIPアドレスを先ほど作成したRestrectedIPポリシーにセットします。

    "Condition": {"NotIpAddress": {"aws:SourceIp": [
      "XXX.XXX.XXX.XXX/32"
    ]}}

再度、IAMユーザでAWSコンソールにログインしてIAMサービスにアクセスできるか確認してみましょう。
今度はアクセスできると思います。

AWSのセキュリティの概要を学ぶ

AWSは非常に便利ですが、大規模な環境を容易に作成できてしまいます。第三者に不正利用されてしまうと、知らない間に大規模にEC2インスタンスが作成され、高額な請求がされてしまうという事になりかねません。現にアクセスキーをGitHubやブログなどにうっかり公開してしまい、それを第三者により使用され高額な請求が上がってしまったという事例もあるようです。CPUを大規模に利用してBit Coinの発掘をするのに利用したりされているようです。
AWS利用者としては、そのような不安を抱えながら利用したくはありません。そこでAWSのセキュリティはどのような仕組みで成り立っており、利用者はどのような考慮しなければならないのかを勉強していきたいと思います。

AWSセキュリティプロセスの概要

セキュリティの概要をまず理解するには、以下のドキュメントがちょうど良さそうです。

セキュリティプロセスの概要 | AWS

今回は、こちらを参照しながら勉強していこうと思います。

AWSのセキュリティモデル

f:id:tmnj:20170108175258p:plain

グローバルインフラストラクチャ

これは、AWS利用者ではなく、アマゾンウェブサービスが全面的に責任を負う部分になります。
AWS上で稼働するサービスのもととなる、ハードウェアやソフトウェア、ネットワーク・データセンターなどの施設で構成されます。この一番基盤となるインフラストラクチャを保護するのはAWSにとっては最優先事項となりますが、AWSの顧客は直接見ることは出来ません。その代わりに、サードパーティの監査会社からのレポートを受け取ることが出来るようになっています。

グローバルインフラストラクチャに加えて、マネージドサービスに該当するサービス(DynamoDB、RDSなど)の製品セキュリティもAWSの責任の範疇となります。以下のように記載されています。

これらのサービスについては、ゲストオペレー ティングシステム(OS)やデータベースのパッチ適用、ファイアウォールの設定、災害対策などのセキュリティタスクを AWS が行います。

AWS顧客が実施するのは、アカウントの認証情報を保護するのみとなります。
逆にマネージドサービスかどうかにかかわらず、アカウントの認証情報は顧客の責任でしっかりと管理する必要があります。これが漏洩して、不正利用されてしまっても、顧客の責任とみなされると思いますので、注意しましょう。よくあるのが、アクセスキーをうっかりコードの一部としてGitHubなどに公開してしまって、不正利用されてしまうことです。こういったことのないように自分が責任を持って保護しなければならない認証情報が何なのかを把握しておきましょう。そうすれば何も心配はありません!

マネージドサービス以外のIaaSに該当するサービス(EC2、VPC、S3)などの場合は、インスタンス含めて顧客がセキュリティタスクや、管理タスクなど完全に管理する必要があります。

逆にマネージドサービスは、そういった作業は不要です。
以下引用です。

マネージドサービスでは、インスタンスの起動や管理、ゲ スト OS やデータベースのパッチ適用、データベースのレプリケートなどに頭を悩ませる必要はありません。

ただし、先程も記述しましたが、認証情報の保護は顧客の責任となりますので、きちんと管理しましょう。

ただし、ユーザーに個々の認証情報を付与して役割分担を行えるように、Amazon Identity and Access Management(IAM)による AWS アカウント認証情報の保護と個々のユーザーアカウントの設定は、 他のサービス同様お客様自身で行う必要があります。また、AWS では各アカウントに多要素認証(MFA)を使用し、 AWS リソースへのアクセスに SSL/TLS の使用を義務付け、AWS CloudTrail で API/ユーザーアクティビティのログを記録 するように設定することを推奨しています。

AWSデータセンターのセキュリティ

Amazonはもともと、本業のリテールの方で大規模なデータセンター運用実績があり、ノウハウを持っていて、それをAWSの運用に活用しているようです。実際の運用経験をもとにしているので、普段からヘビーなAmazonユーザとしては、机上の空論ではなくこれほど説得力のあるデータセンター運用もないかと思います。
Amazonという最大の事例があるので、事例大好き日本人にはすごく安心できますよね!

データセンターも含めて、あらゆるサービスがすべてアクティブでN+1構成の考え方を原則にして構成されているようです。顧客がCloud上でシステムを構築する際は、従来のActive/Stanby型ではなく、あらゆるものをN+1アクティブ構成を基本に設計するのが今後のクラウド時代の鉄則となるのではないでしょうか。

ネットワークのセキュリティ

自分は、ネットワーク周りに苦手意識が強いので、今後は集中的に勉強していきたいと思っています。
AWSでは、ファイアウォールなどの境界ネットワークデバイスで、アクセス・コントロール・リスト(ACL)により設定ベースで制御できます。

また、セキュリテイグループなどにより、アクセスポイントに対してInbound/Outboudの通信許可を設定することが可能です。
ネットワークの監視機能もあります。

このあたりの詳細は、後日じっくりと勉強していきたいと思います。

AWSアカウントのセキュリティ機能

AWSにかぎらずに多くのクラウド利用ユーザの心配事は、自分のアカウントがちゃんと保護されていて、不正利用されないかどうかだと思います。
そのために自分のアカウントが不正利用されないようにしっかりと自身の認証情報を管理、保護しておく必要があります。
ただAWSでは不正利用から保護するための様々な機能を提供しているので、必要以上に恐れる必要はありません。ただし、自身が保護して置かなければならない情報が何なのかは、きちんと把握しておきましょう。当然パスワードなどのわかりやすいものは誰にもバレないようにするというのは、ITリテラシーの一般教養だと思いますが、万が一漏洩してしまったらとか、一見パスワードじゃないもの(アクセスキーなど)をうっかりコードに書いてGitHubにあげてしまった場合など、何が起きるかきちんと理解して適切な情報保護をしましょう!

AWSの認証情報の種類

AWSは複数の認証情報を利用して、AWSアカウント及びリソースへのアクセスを制御します。
アカウントに対して、他要素認証(MFA)を利用することも可能です。
以下、ASW認証情報の種類一覧になります。

認証情報の種類 使用アイテム 説明
パスワード AWS マネジメントコンソールへの AWS ルートアカウントまたは IAM ユーザーア カウントのログイン AWS アカウントまたは IAM アカウントへのログインに 使用する文字列です。AWS パスワードの最小文字数 は 6 文字、最大文字数は 128 文字です。
Multi-Factor Authentication(MFA) AWS マネジメントコンソールへの AWS ルートアカウントまたは IAM ユーザーア カウントのログイン AWS アカウントまたは IAM ユーザーアカウントにログ インする際に、パスワードに加えて要求される 6 桁の ワンタイムコードです。
アクセスキー AWS API へのデジタル署名付きリクエス ト(AWS SDKCLI、または REST/クエリ API を使用) アクセスキー ID とシークレットアクセスキーが含まれ ます。アクセスキーを使用して、AWS へのプログラム によるリクエストにデジタル署名します。
キーペア -EC2 インスタンスへの SSH ログイン
-CloudFront の署名付き URL
キーペアは、パブリック AMI から起動された EC2 イン スタンスに接続するときに必要になります。Amazon EC2 が使用するキーは、1024-bit SSH-2 RSA キーで す。キーペアは、インスタンスの起動時に自動的に生 成することも、手動でアップロードすることもできます。
X.509 証明書 - AWS API へのデジタル署名付き SOAP リクエスト
- HTTPS 用の SSL サーバー証明書
X.509 証明書は、SOAP ベースのリクエストに署名する ときにのみ使用されます(現在は Amazon S3 でのみ 使用されています)。AWS ではダウンロード可能な X.509 証明書とプライベートキーを作成できます。ま た、[Security Credentials] ページを使用して、独自の 証明書をアップロードすることもできます。


上記で特に注意しなければならないのは、アクセスキーです。アクセスキーはプログラムからAWSのリソースをコントロールする際に利用されますが、うっかりスクリプト内にアクセスキーを入れてたまま、GitHubやブログなど外部に公開された場所に情報を置いてしまい、それを元に不正利用されるということが実際に起こっているようです。ただ、アクセスキーは保護すべき対象ときちんと認識した上で、絶対に公開しない、不要なアクセスキーは作らないなどの対応を徹底しておけば問題ありません。なお、下記ブログの方は不正利用分は免除されたようです。良かったですね!AWSサポートは素晴らしいですね。

d.hatena.ne.jp

海外の方の事例もあります。こちらはうっかりGitHubに公開してしまったようです。

xingwu.me


念のため、不正利用が発覚した場合の対処方法は以下に載っていますので、いざという時には参照してみて下さい。

Resolve Issues with Potentially-Compromised AWS Accounts

なお、現在は、GitHubにアクセスキーをアップしてしまっていると、AWS側からアカウントがロックされてしまうこともあるようですので、お気をつけ下さい。

cohakim.com

何度も言いますが、アクセスキーは保護すべき重要な認証情報です。うっかり公開して後悔しないようにしましょう!

アカウント保護のポイント

アカウント保護のポイントとしては、

  • 認証情報は絶対に漏らさない。アクセスキーも含まれます。そもそもコード中に埋め込むという習慣はなくしましょう!IAMロールを活用することも検討すべきだと思います。
  • 多要素認証(MFA)をきちんと設定しておきましょう。(ただし、デバイスの機種変更などする際は、きちんと引き継げるように準備してから行いましょう!)
  • 適切な権限を絞るためにIAMユーザを作成しておきましょう。
  • 不要なアクセスキーは作らない。特にルートのアクセスキーを作成するのはなるべくやめておきましょう!


次回以降は、AWS個々のサービス毎のセキュリティを興味が出た順番で勉強していきたいと思います!

iPhoneを交換したらAWSのMFAができなくなってしまった。そんな時の対処法

先日、iPhone6sのバッテリー問題で新しいiPhoneに交換しました。
やっと、突然シャットダウンしてしまう問題から開放できたと喜んでいたのですが、新しいiPhoneをバックアップから復旧した後に、AWSコンソールにログインしようとGoogle Authenticatorを起動してみたら、なんとびっくりAWSの設定が消えてしまっていました。

とはいえ、新しく登録しなおせばいいのだろうと思って、パスワードでログイン後に表示される認証コード入力画面で、「認証デバイスに問題が有りますか?ここをクリック」をクリックしてみました。
しかしこの画面から再度AWSの設定が復旧するわけではないようです。そういえば、最初の設定段階でQRコードを読み込んでアカウントを登録したように記憶しています。これが出来ないと再度、MAFの設定ができない。当然といえば当然でした…。
しかし、ログインできないと何も操作できないわけで…。

解決するにはどうすればいいの?

よく見ると、画面右にContact Usボタンがありました。

f:id:tmnj:20170108022722p:plain

説明文には以下のようにあります。デバイスをなくしたわけではないですが、新しくしたわけなので、こちらのボタンを押してみました。

If you are unable to sign in because your authentication device is lost, damaged or not working properly, we will need to have an Amazon Web Services customer service representative help you regain access to your account. Please contact us with the details of your situation so we may further assist you.

そうすると、次のような画面が表示されます。まだ日本語訳画面ではないようですが、電話番号を入れるとAWSサポートから折り返し電話が来るようです。

f:id:tmnj:20170108014027p:plain

ただ、下の方に書いているように、最初の電話は英語ですが日本語のサポートを希望すれば(英語で)、日本語でのサポートもされるようです。
早速必要項目を入力してみました。

取り敢えず、理由としてはバッテリー故障に伴うiPhoneの変更なので、一番上の"My device was lost, stolen, or damaged."を洗濯して、自分の携帯の電話番号を入力します。一応+8190XXXXXと国際番号表記で入力してみました。

しばらくすると、携帯にシアトルの番号(iPhoneにシアトルと表示されていました。)から電話がかかってきました。恐る恐る取ります。取り敢えずHello!と。
自分はあまり英語が得意ではないので、iPhoneを交換したら仮想MFAが利用できなくなってしまったと伝えたのと、あまり英語が上手くないことを伝えると、日本語サポートが必要ですか?と聞かれましたので、Yesと答えました。そうすると、Japanサポートに連携すると言って電話は切れました。

しばらくしたら、AWSアカウントを登録しているメール宛に日本語サポートに連携した旨のメールが届きます。
さらに2−3時間程したら、AWSの日本のサポートの方から連絡が来ました。なぜか非通知でしたが…。

まずは、事情を説明するとMFAをサポート側で解除するということでした。実施した手順としては、

  1. 自分のメールアドレスをサポートの方に伝える
  2. メールが届くとワンタイムパスワードがメールに記載されているのでそれをサポートの方にそのまま電話で伝える
  3. するとすぐにMFAが解除できましたとサポートの方から言われます。

MFAが解除されれば通常のID/PWでログインできますので、新しいiPhoneで仮想MFAデバイスとして登録しなおせば万事解決しました。
注意点としては、日本語サポートは日本の営業日9:00〜18:00の間だけですので、休日や深夜に緊急にアクセスしなければならないという場合は英語での対応が必須となります。ただ、おそらくその場合も上記のような流れになるだけだと思いますので、落ち着いて対応すれば問題なくMFA解除してもらえると思います。

そもそもiPhoneを変えるたびにこんなことをするのは面倒なのでは?➛ Authyを使おう!

会社とかの組織でAWSを利用していれば、こんな時もちゃんとしたハードMFAデバイスなどが用意されていたり、複数デバイス持っていたりとすると思いますが、個人だとうっかりこういうことは起こってしまいますね。
今回であれば、iPhone交換前にAWSにログインして、MFA設定をオフにしておいて、新規iPhoneが入手できたら再度MFAの設定を実施という流れを取っていれば回避できます。しかし突然、デバイス故障となるとそういう方法も取れません。

今回は、Google Auchenticatorを利用していましたが、代わりにAuthyというアプリが利用できます。Authyは情報が暗号化されてバックアップされ、Authyに登録した電話番号とパスワードで復旧することが出来ます。使うならこっちのほうが良いですね!

みなさんも仮想MFAを利用している場合は気をつけて下さい。

もう一つ解決策としては、以下のサイトに書いてあるように、QRコードやシークレットキーのコピーを保存しておくというものです。

多要素認証(MFA)仮想デバイスの有効化 - AWS Identity and Access Management

Important
仮想 MFA デバイスが AWS と連携するように設定する場合、QR コードまたはシークレットキーのコピーを安全な場所に保存しておくことをお勧めします。こうすることで、電話を紛失した場合や、MFA ソフトウェアアプリケーションを何らかの理由で再インストールする必要がある場合に、同じ仮想 MFA を使用し、ユーザーまたはルートアカウントが新しい仮想 MFA AWS を作成する必要がないように、アプリケーションを再設定できます。

ただ、これだと保管場所の管理とか煩わしいので、個人利用の場合はあまりこの方法は取りたくないですね…。

色々記載しましたが、今回自分も無事に解決できました。
いざという場合は、AWSのサポートは非常に頼りになりますのでいざこのような自体になっても大丈夫ですよ!ご安心を!

iPhone 6sが突然シャットダウンしてしまうバッテリー問題はエクスプレス交換が便利!

iPhone 6sの噂のバッテリー問題、以前からたまにバッテリー残量があるにも関わらず突然シャットダウンしてしまう事が発生していたので、下記のURLにてシリアル番号から調べてみると見事ヒットしていました。
iPhone 6s が突然シャットダウンする問題に対するプログラム - Apple サポート

ただ、Apple Store直営店や提携サービスショップにiPhone6sを持ち込んでまるっと入れ替える必要があり、面倒なので嫌厭していたのですが、最近この問題が頻繁に発生するようになってしまい重い腰を上げました。1日に何度も、ひどい時では100%のときに落ちてしまう場合もありましたので・・・。

バッテリー問題はエクスプレス交換なら自宅にいながら無償で交換

結論から言うと、エクスプレス交換という方法が有り、店舗に行かなくても自宅で新規デバイスと交換するという方法で非常に簡単かつ自分の都合に合わせて対応ができました。
エクスプレス交換は、AppleiPhoneを送ってから修理品を受け取るというものではなく、宅配便の人が新しいiPhoneを自宅まで持ってきて、玄関先で古いiPhoneと交換という方法となります。端末が手元にないブランク期間を作ること無く自宅で交換できますので、非常に便利でした。

たった二日で交換完了!

自分が申込んだのは、新年早々の2017/1/4の夕方くらいでしたが、1/6(金)の午前中には新しい端末が届きました。Appleサポートの人は在庫が足りなくて1週間ほど掛かるかもと言っていましたが、思った以上に早く届いて非常に満足でした。なお、当方は東京住みです。
ただ、今回はたまたま在庫があって運が良かったのかもしれません。

エクスプレス交換ではヤマト便で配送され、発送後は時間指定で好きな日時に変えられますので自分の都合にすごく合わせやすいです。


エクスプレス交換の方法は?

エクスプレス交換の方法ですが、まず、上記のサイトで自分のiPhone6sが交換対象かどうかを調べます。もし交換対象だった場合は、上記サイトのAppleテクニカルサポートへのリンクからテクニカルサポートに問い合わせします。自分は電話で問い合わせをしましたが、2分程ですぐに繋がりました。
上記URLからたどると既に問い合わせのトピックとしては、iPhone6sバッテリー問題に設定されていますので非常にすんなりと話が進みます。口下手の方も安心です!!

そこで、エクスプレス交換という方法をおすすめされました。
ただ、自宅で交換という方法のため、Express交換予約後にクレジットカードを登録して7万円ほどの承認枠が確保されます。これは仮に古いiPhoneAppleに届かなかったり、不適格なiPhone(脱獄や水没など)だった場合に料金が引き落とされるそうです。その場合は7万円ほどかかります。正常に返却できれば承認枠は解除されます。このバッテリー問題はApple側の責任なので全て無償で実施できます。通常は料金のかかるエクスプレス交換も無償で実施できました。


クレジットカードでの支払い登録はサポートへExpress交換手続きをした後にメールで届きます。この情報を入力して手続きが完了ということになります。

なお、もし"iPhoneを探す"が有効になっていると電話口で解除するように促されますが、新しい端末が届くまで時間がかかる場合はiPhoneを探すを再度有効にしておいても大丈夫とのことでした。ただし、宅配便の人に渡す際に必ず"iPhoneを探す"はOffにしておいてくださいとのことです。

申し込み後の流れ

さて、エクスプレス交換を申し込んだ後に、iPhoneが発送されると発送メールが届きます。そこにヤマト便のリンクが記載されていますので、宅配日時を自分の都合のよい日時に設定しましょう。
届く日時の直前に以下のことを実施しておきます。

  • バックアップを取る
  • iPhoneからsimカードを引っこ抜いておく
  • iPhoneを探すをOffにしておく
  • iPhoneをリセットしておく
  • ケースや液晶保護シートなどは外しておく

なお、これらはエクスプレス交換を申し込むと上記の手順がメールで送られてきますので具体的な手順はそちらで確認できます。

iPhoneが送られてきたら、宅配便の人からiPhoneの入った箱を渡されるので、その場で自分で開けます。新しいiPhoneを取り出したら、古い自分のiPhoneを箱に入れ直して宅配便の人に渡します。交換手順そのものは以上です。なお、届くのはiPhone本体のみで、イヤホンや電源コードなどは付属していません。交換時に渡すのもiPhone本体のみになります。

最後に復元しますが、自分の手元に届いたiPhoneiOSのバージョンが古かったらしくそのままでは、iTunesからバックアップの復元ができませんでした。なので、一旦新しいiPhoneとして起動してiOSを最新にバージョンアップした後に、バックアップから復元しました。
若干面倒な作業ですが、1時間ほどで完了しました。

エクスプレス交換は自宅にいながら対応できますので、非常におすすめです!
店舗に持っていくのが面倒だったり都合が付きづらかったりする方、近くに店舗が無い方などは、この方法が良いかと思います!

MacBook Pro 2016で3本指ドラッグを有効にする

先日やっと、新型MacBook Proが家に届きました。以前利用していたのは2008 Later MacBookです。
SSDに換装したり、バッテリーも2回も交換して使い続けていましたが、新OSが対応しなくなってしまい止む無く買い替えました。

さて、実施に新MacBookをいじっていてハマったのが3本指ドラッグの設定です。ここでは、3番指ドラッグの設定方法を記述します。

まず最初にトラックパッドの設定で、”3本指で上下にスワイプ”を変更

ハマったのがこの設定です。Mac>システム環境設定>トラックパッド>その他のジェスチャ
ここでは、デフォルトで以下のようにMission ControlとアプリケーションExposeの設定が3本指で上下にスワイプに設定されています。

f:id:tmnj:20161217123347p:plain


これをそれぞれ以下のように4本指でスワイプに変更します。

f:id:tmnj:20161217123448p:plain

次に、アクセシビリティの「マウスとトラックパッド」でドラッグを有効にする

システム環境設定>アクセシビリティ>マウスとトラックパッドで、「トラックパッドオプション」ボタンをクリック

「ドラッグを有効にする」チェックボックスをオンにして”3本指のドラッグ”を選択する。

f:id:tmnj:20161217123643p:plain


これで、3本指のドラッグが有効になります。なお、トラックパッドの設定で3本指でスワイプに再度変更すると、3本指ドラッグは自動的に無効になりますので、ご注意ください。

どうやら、3本指のスワイプと3本指のドラッグは同時に有効化は出来ないようです。自分は3本指ドラッグが絶対に外せません。4本指スワイプでも全然困りませんしね。

Apache Sparkの勉強-Clusterを構成してみよう!spark-ec2スクリプトでクラスタ簡単構築

f:id:tmnj:20161213134842p:plain

今日は、自動でec2インスタンスを作成してSpark Clusterを構成してくれるspark-ec2ツールを利用してクラスタを構成してみます。

正式なサイトは以下です。こちらに書かれている内容に沿って実施してみます。

github.com

ツールの概要

spark-ec2は、Apache Sparkクラスタをec2上で起動・管理・シャットダウンできるツールです。Apache SparkとHDFSクラスタ上に自動で構成してくれます。
ツールでは同時に複数のクラスタを扱うことができますが、クラスタはec2インスタンスが所属するセキュリティグループにより識別されます。たとえば、testという名前のクラスタには、マスターノードはtest-masterと呼ばれるセキュリティグループ内に、複数のスレーブノードは、test-slavesというセキュリティグループ内に含まれます。spark-ec2スクリプトは、要求したクラスタ名に基づいて、これらのセキュリティグループを自動で作成します。

事前準備

  • 当然ですが、awsのアカウントは事前に作成しておきます。
  • 利用するKey Pairを作成しておきます。これはAWS Console上で作成できます。
  • AWS_ACCESS_KEY_IDとAWS_SECRET_ACCESS_KEYに自身のec2 access keyとsecret access keyをセットしておきます。
    • AWS Homepageへ行き、アカウント > セキュリティ認証情報をクリックしてアクセスキーから作成できます。
    • アクセスキーとシークレットキーはセキュリティ上、絶対に外部に漏らさないようにしてください。特にスクリプトに直書きして、GitHubのPublicリポジトリに公開などしないように注意してください。この情報が漏れると不正利用されます。特に大規模なBitCoin発掘用途でEC2インスタンスを不正に大量作成されてしまうという被害があるようです。

作業用のec2インスタンスの作成

作業用にec2インスタンスを1つスポットインスタンスで作成しておきます。

作成方法は以下の記事を参照してください。

tmnj.hatenablog.com

作業用ec2インスタンスへspark-ec2のインストール

spark-ec2はGitHubから入手できます。

$ sudo install git
$ git clone https://github.com/amplab/spark-ec2.git

なお、spark-ec2はspark 1.6.3以前はspark本体に同梱されていましたが、2.0.0から上記GitHub上に分離されました。*1

クラスタの起動

では早速起動してみます。上記で取得したspark-ec2ディレクトリに移動します。

以下のようにアクセスシークレットキーとアクセスキーを環境変数にセットします。(以下の値はダミーです。)
注意: 自身のアクセスキー情報は絶対に外部に漏らさないでください。また、テストが終わったらアクセスキーは削除しておきましょう!

export AWS_SECRET_ACCESS_KEY=xxxxxx
export AWS_ACCESS_KEY_ID=xxxxxx

private-key.pemという名称で、ec2インスタンス作成に利用するKey PairのPrivate Keyをセットしておきます。
以下のように600をパーミッションとしてセットしておきます。

chmod 600 private-key.pem


次に、インスタンスを作成するリージョン名とアベイラビリティ名を調べておきます。
リージョン名は以下のURLから参照できます。

リージョンとアベイラビリティーゾーン - Amazon Elastic Compute Cloud


リージョンで利用可能なアベイラビリティゾーンは、以下のURLを参照してください。

リージョンとアベイラビリティーゾーン - Amazon Elastic Compute Cloud


ここでは、東京リージョン(ap-northeast-1)のap-northeast-1aを利用します。

以下のようなコマンドを実行します。

./spark-ec2 \
  --key-pair=admin-key-pair-tokyo \
  --identity-file=private-key.pem \
  --region=ap-northeast-1 \
  --zone=ap-northeast-1a \
  --instance-type=c3.large \
  --slaves=3 \
  --spot-price=0.03 \
  --hadoop-major-version=2 \
  launch spark-ec2-cluster


インスタンスタイプはc3.largeを指定して、slave数を3インスタンスとしています。また、--spot-priceを指定することでスポットインスタンスを作席できます。価格はec2ダッシュボードのスポットリクエストから調べることができますので現状の値を下回らない値を指定してください。
--hadoop-major-version=2は、これを入れないとsparkのダウンロードが404になってしまうため指定しておきます*2

途中でsshがrefuseされたエラーが出るかもしれませんが、おそらくec2がまだ準備中のためであり、しばらく待っていれば処理が進むと思います。(5~10分ぐらい)もし、private-keyのパーミッション設定などが間違っていた場合は、一旦停止して、--resumeをつけて再実行してみてください。

トータルでは15分ぐらいかかると思います。コーヒーでも飲んで待ちましょう!


ただ、デフォルトだとSpark1.6.2がインストールされるっぽいです。--spark-version=2.0.2を指定すると最初のバージョンチェックでエラーとなるため、動作が不明です。今後調査します。

インストールが完了すると、以下のようにMaster Web USが表示されます。

Spark standalone cluster started at http://ec2-xx-xx-xx-xx.ap-northeast-1.compute.amazonaws.com:8080
Ganglia started at http://ec2-xx-xx-xx-xx.ap-northeast-1.compute.amazonaws.com:5080/ganglia
Done!

Master Web UIにアクセスすると、以下のようにMaster/Workerが構成されています。

f:id:tmnj:20161213162736p:plain

クラスタを止める

以下のコマンドでec2インスタンスごと止まります。

./spark-ec2 --key-pair=admin-key-pair-tokyo --identity-file=private-key.pem --region=ap-northeast-1 --zone=ap-northeast-1c destroy spark-ec2-cluster

まとめ

大規模なクラスタ環境をec2上に作成する場合は非常に便利かもしれません。
ただ、内部的にブラックボックスな部分が多いので、ちゃんと理解するにはまだまだ勉強が足りません…。

Apache Sparkの勉強-Clusterを構成してみよう!クラスタ起動スクリプトで一発起動してみる

http://spark.apache.org/images/spark-logo-trademark.png


前回は、SparkのStandaloneクラスタを手動スクリプトで構築して、対話シェルで動作を確認してみました。

tmnj.hatenablog.com


今回は、クラスタ起動スクリプトを使用してスクリプト一発実行するだけでSparkがクラスタ構成で起動する方法を実施してみたいと思います。

環境の準備


前回記事の環境を使います。
各EC2インスタンスの同一のディレクトリにSparkをインストールしておきます。

クラスタ起動スクリプトの利用

まず、conf/slavesファイルをSparkディレクトリに作成する必要があります。このファイル内には、Spark workerが動作するホスト名を1行ずつ定義します。なお、SlaveマシンへはMasterマシンからsshでアクセスできる必要があります。デフォルトでは、パスワードなしでPrivate Keyアクセスができる必要があります。EC2の各インスタンスでは作成時に指定したKeyペアのPublic Keyはsshに設定されていますが、Masterインスタンスからアクセスする際のPrivate Keyを指定する必要があります。
(注意:本番環境などの場合は、別途EC2インスタンス間のアクセスで利用するKeyPairを作成してそちらを利用するようにしましょう!)

まず、EC2インスタンスで使用したPrivate KeyをMasterインスタンス上の任意のディレクトリにアップします。(例えばSPARK_HOME/private-key.pem)次に以下のようにSPARK_SSH_OPTSに"-i"オプションでprivate keyファイルを指定しておきます。(ファイル名は適宜変更してください。)なおpemファイルはchmod 400で自分しか読めないようにパーミッションを変更しておきます。

chmod 400 private-key.pem
export SPARK_SSH_OPTS="-i private-key.pem"


ここまでそろったら、./sbin/start-all.shを起動するとローカルのMasterとリモートのSlaveがすべて起動します。

 ./sbin/start-all.sh

エラーが無ければ無事に起動できています。masterのログを見ると以下のようなログが出ていれば、workerが起動してMasterに登録されています。

16/12/12 13:10:10 INFO Master: Registering worker xx.xx.xx.xx:44238 with 2 cores, 2.7 GB RAM
16/12/12 13:10:10 INFO Master: Registering worker xx.xx.xx.xx:36147 with 2 cores, 2.7 GB RAM

実際にブラウザからMaster WebUIにアクセスしてみましょう!
masterインスタンスに8080ポートでアクセスします。(sshトンネリングするか、セキュリティグループに8080アクセスをセットしておきます。送信元IPはマイIPのみ許可するようにしておきましょう。)

http://maser-ec2-instance-dns:8080

以下のように、Workerが追加されています。


f:id:tmnj:20161212221830p:plain



前回のように、対話シェルで動作確認してみましょう!

conf/slaveファイルにホストを追加すれば自動で起動されますので便利ですね!

止める場合は以下を実行します。

./sbin/stop-all.sh

まとめ

クラスタ起動スクリプトを利用すると大量ホストをワーカーにする場合は取っても便利!