MyCSS

2011/04/20

S3とIAMを組み合わせたお手軽ファイル共有 はてなブックマークに追加

AWSを使ったお手軽ディザスタリカバリ対策を社内で構築したお話を書きましたが、その続きです。

ファイル共有としてS3を使おうとした経緯
ファイルをやり取りする時など、イントラにあるファイルサーバー(SambaやAFP、NFSなど)を経由させるのが一番お手軽な方法だと思います。実際、最近のNASは安いですし、RAIDも簡単に組めてそこそこ信頼性もあります。ちなみに弊社ではBuffaloのTera Stationを利用しています。

ですが、このファイルサーバーをクラウドに持って行くとなると結構大変です。弊社の場合ですと、エンジニアと印刷オペレーターとでファイルをやり取りする機会も多いので、エンジニア以外の人たちでも簡単に扱える仕組みが必要となります。AWSでこの手の「ファイル共有」プロトコルを喋らせるにはEC2を仕立ててあげなければなりませんが、今回はそのような時間もお金もかける事が出来ません。

AWS最強のサービスS3
AWSにはS3という容量無制限のストレージサービスがあります。CloudBerry ExplorerCyberduckを使えば、FTPライクに扱う事が出来ますし、AWS純正のAWS Management Consoleはブラウザで利用出来るので、基本的なPCリテラシーがある人であれば扱えるものです。
※ただし、UIの日本語化が行われていませんので、場合によっては問題になるかもです。

そこで、ファイル共有の代わりにこの辺のツールを使う事にして、あとはファイルの書き込み、読み込みなどの権限管理をIAM(Identity and Access Management)を利用して設定してみました。

IAMに関しては、サーバーワークス小倉さんがJAWS-UGの勉強会で発表してくださった超わかりやすいスライドがありますので、そちらをご覧ください。

IAMまわりのツール
今の所IAMの設定は、AWS Management Consoleから扱えません。しかし、日本にはCloudworksという神サービス(笑)があり、こちらでIAMをサポートしています。また、FirefoxエクステンションのIAM Foxもあるので、コマンド叩くの嫌だ!という人でもだいぶ敷居が低くなっています。ただ、細かい所をいじるには、やはりコマンド、もしくはSDKを使ってAPIを叩かなければなりません。

また、設定自体はAccess Policy Languageと呼ばれる形式(中身はJSON)で書く必要があるので、それなりに大変です。ですが、JSONを生成してくれるAWS Policy Generatorが用意されているので、イチから手書きするよりも、こちらを使う方が良いかもしれません。

この記事では Policy GeneratorでJSONを作成 → 少々手直し → Cloudworksにて設定
いうやり方で行いました。その他、GUIのツールでサポートしていない部分はコマンドラインを利用しました。

概要
考え方としてはこのような感じです。
  • ファイルサーバーとして利用するバケットを一つ作ります。リージョンはもちろん東京です。このバケットを仮に「共有バケット」と呼ぶ事にします。バケット名は「s3-shared」とします。
  • 印刷部門の人間には、この共有バケットに対してのみ、自由に読み書きが出来ます。
  • その他バケットは、管理者以外は読み書き出来ない事とします。

IAMで「admin」と「s3-user」という二つのグループを作ります。adminは管理者権限、s3-userはS3の共有バケットの読み書きのみ出来るという意味です。adminグループにはadminというユーザー、s3-userグループにはkenとsachikoというユーザーがいるとします。(名前に他意はありませんよw)



CloudworksでIAMを設定する
まずはユーザーを作らないと何も出来ません。コマンドでのやり方はググれば沢山出てくるので、Cloudworksでのやり方を説明してみます。

Cloudworksにログインし、左のIAMユーザーを選択、右上の「IAMユーザーの追加」をクリックします。admin、ken、sachikoというユーザーを作成します。



次にadminグループとs3-userグループを作成します。

adminグループ配下にユーザーadminを、s3-userグループ配下にkenとsachikoを入れます。グループを選択して、「IAMユーザーをグループに追加」をクリックします。以下の画面は、s3-userを選択した場合です。

s3-userグループにkenを追加します。追加するユーザーは、ちゃんとプルダウンで選択出来るようになっているので便利ですね!

同様にsachikoも追加して、s3-userグループの設定が完了しました。

ポリシーの記述
さて、ここからJSONでポリシーの記述を行います。ここではAWS Policy Generatorを使ってみます。

AWS Policy Generator

まずは、adminからやってみます。

adminはS3だけではなく、その他のサービスも全て利用出来るものとしますので、All Servicesにチェックを入れるだけです。

「Add Statement」をクリック、「Generate Policy」をクリックすると、このようにJSONが生成されます
このJSONをCloudworksにコピペするという訳です。

Cloudworksに戻ります。adminグループのIAMグループポリシーの追加をクリックします。ポリシー名は何でも良いのですが、判りやすくadmin-policyとでもしておきましょう。

次に、s3-userのポリシーを作成します。Policy Generatorに戻って、以下の事をやります。
  1. Type of PolicyはIAM Policyを選択
  2. EffectはAllow、AWS ServiceはAmazon S3を選択。以下の操作も同じ。
  3. ActionsでListAllMyBucketsを選択。Amazon Resource Name(ARN)には、 arn:aws:s3:::* と記入。「Add Statement」をクリック。
  4. ActionsでListBucketGetBucketLocationを選択。ARNは arn:aws:s3:::s3-shared と記入。「Add Statement」をクリック。
  5. ActionsでAll Actionsをチェック。ARNは arn:aws:s3:::s3-shared/* と記入。「Add Statement」をクリック。
結果、このような感じになります。

出来上がったポリシーはこんな感じです。
{
  "Statement": [
    {
      "Sid": "Stmt1303292722962",
      "Action": [
        "s3:ListAllMyBuckets"
      ],
      "Effect": "Allow",
      "Resource": "arn:aws:s3:::*"
    },
    {
      "Sid": "Stmt1303292848143",
      "Action": [
        "s3:GetBucketLocation",
        "s3:ListBucket"
      ],
      "Effect": "Allow",
      "Resource": "arn:aws:s3:::s3-shared"
    },
    {
      "Sid": "Stmt1303292879145",
      "Action": "s3:*",
      "Effect": "Allow",
      "Resource": "arn:aws:s3:::s3-shared/*"
    }
  ]
}

まず、IAMのデフォルトポリシーは全てDenyです。Allowを付け加えて行くやり方で考えています。

ListAllMyBucketsとは、S3バケットの一覧を表示するかどうかです。これはDenyしても良さそうですが、Management Consoleでは左側にバケット一覧が表示される為、Allowしておく必要があるみたいです。(情報求む)

共有バケット名は「s3-shared」です。これをARNで書くと arn:aws:s3:::s3-shared となります。ここに対してGetBucketLocationとListBucketをAllowしてやると、このバケット内のオブジェクト一覧を取得する事が出来ます。

さらに、このバケット内部を読み書きする為には、arn:aws:s3:::s3-shared/* に対して全てのActionをAllowしてやります。これは文字通り全てのアクションを許可してしまうので、例えばファイルのパーミッションにあたるACL(Access Control List)の変更もs3-userグループの人が出来てしまいます。この辺はどこまで制限するかによるでしょう。

このJSONをCloudworksにコピペします。

これでIAMの設定は終わりました。

s3-userでAWS Management Consoleを使う場合
通常、Management Consoleにアクセスするには、
  • https://console.aws.amazon.com/s3/home
に行くと思いますが、ここで入力するのはAWSアカウントのEメールとパスワードです。せっかくIAMを設定したのに、これではログイン出来ません(笑)

IAMでManagement Consoleにログインする為には、特別なURLが用意されています。(参考:AWSドキュメント
  • https://your_AWS_Account_ID.signin.aws.amazon.com/console/s3
your_AWS_Account_IDは、AWSアカウントに設定されている12桁の数字です。ただ、この数字を覚えている人は極めてまれだと思いますので、AWSアカウントIDのエイリアスを作って覚えやすいURLに変更してしまいましょう。下記のコマンドを打ちます。

$ iam-accountaliascreate -a hogehoge
Alias: hogehoge
Direct Signin Link: hogehoge.signin.aws.amazon.com

これでめでたく、https://hogehoge.signin.aws.amazon.com/console/s3でログインする事が出来るようになりました。

さて、ユーザー名とパスワードを入力してログインしてみましょう…って、パスワードってどこかで設定しましたっけ?(笑)

実は、このパスワードの設定はCloudworksでは出来ません。しかたがないので、コマンドを打ちましょう。

$ iam-useraddloginprofile -u ken -p PASSWORD

これでようやくログインする事が可能になります。


ログインするとおなじみのコンソール画面が出て、バケット一覧が表示されます。試しに共有していないバケットをクリックしてみるとこんな感じでアクセス出来ません。うまく設定出来ているようです。

共有バケットは、自由にフォルダを作ったり、ファイルをアップロード/ダウンロードが出来ます。sachikoユーザーでも全く同じ事が出来ます。

s3-userグループは、S3の共有バケットの操作のみ許可されていますので、もちろんEC2は触れません。
もちろん、Elastic Beanstalkも無理です。

こんな感じで、共有バケットの操作のみに権限を絞ったIAMユーザーに対して、AWS Management Consoleを使ってもらう準備ができました。めでたしめでたし。

CyberduckやCloudBerry Explorerの場合
これらのツールを使う場合は、先ほど作ったIDとパスワードでは出来ません。従来通りアクセスキーとシークレットアクセスキーを使う必要があります。これはユーザーごとに発行します。

Cloudworksではこのようにやります。
アクセスキーを発行したいユーザーを選択し、アクセスキーの追加ボタンをクリックします。
そうすると、このようにキーが発行されますので、メモっておきます。シークレットアクセスキーは、この画面でしか表示されません。あとで確認する手段がないので、もし忘れてしまったらキーの再発行となります。(これはAWS側の仕様です。コマンドラインでやっても同じ事です。)

Cyberduckでは、ユーザー名にアクセスキーを、パスワードにシークレットアクセスキーを入力します。

共有バケットへはアクセス出来ますし、それ以外はアクセスが拒否される事が判ります。

まとめ
なんか、思いがけず長文エントリになってしまいましたが、ここで紹介している事は非常に単純なものです。ポリシーは時間帯でIP制限をかけるなど、きめ細かく記述出来ますし、そもそもS3だけでなく、EC2などのサービスにも適用出来ます。(私は全然使いこなしていませんがw)
また、Cloudworksのように周辺のツールを組み合わせれば、色々と作業が楽になります。

手軽でセキュアな無制限ストレージが格安で手に入る時代になりました。
いやー、S3って、ほんといいもんですね!

2011/04/19

Twitterアイコンの衣替え! はてなブックマークに追加

最近@crown_sugarこと南暁子さんに描いていただいたアイコンをシールにして名刺に貼ってますが、おかげさまで
「あっ!このアイコン見た事ある!」
と絶叫(?)される事が多い今日この頃ですw

Twitterアイコンの母である南さんは、なんとすでに100人を超える人たちの似顔絵を描いてらっしゃいます。しかもこれだけのクオリティが無料ですよ。すごい創作意欲です。

それで、100人描いてもまだ飽き足らず(?)なんと、過去に描いていただいたイラストを「衣替え」してくれるという、とても嬉しい企画があるんです。応募はハッシュタグ #koromogae を付けてツイート先着順、しかも事前予告なくゲリラ的に告知があるので、運がよいか、24時間TLに張り付くかどちらかしかありません(笑)

自分は、たまたまTLに見かけて、「ktkr!」と思いツイートしたのですが、いざ当選してみて、「はて、何に衣替えするか?」と悩むハメになってしまいました(←ひどい)

で、ふと思ったのが、シール好きな息子。ひょっとして、息子との2shotもアリなのか!?と思いつつ、衣替えの域をはみ出しており、いくら何でも厚かましいんじゃ…などと一巡りした挙げ句、偉大なる母、南さんにお頼み申した結果、無理を聞いてくださいまして描いていただきました!
A4の紙にでかでかと印刷してみせたら息子は大喜び。冷蔵庫に貼って悦に入っておりました(笑)

もちろん PRINTAIL さんでシールを発注。今回は常識的な枚数におさめましたw
ただ、前回と違うのは、シールの台紙が名刺サイズという事です。


この台紙のサイズ、実にいいんですよ!シールの予備を名刺入れに入れておく事が出来るので、意外に便利です。

ちなみに、このようなシャレオツな台紙がセットされてきました。
よーく見ると、透かしの様な印刷がされています。地味に凝ってますね。

という訳で、今度私と名刺交換する方は、このシールがついてくる予定です。(今貼っているソロバージョンの在庫がはけたらですがw)

いやー、アイコンって、ほんとにいいもんですね!

2011/04/14

AWSを使ったお手軽ディザスタリカバリ対策〜Subversion編 はてなブックマークに追加

http://eitar0.pecori.jp/
東日本大震災のあった3月11日は、たまたま有休を取っていて自宅におりました。家族で外出しようとしていた矢先に「グラッ」と来て、結構大きいな、と思いつつ、なかなか揺れが収まらない長い横揺れに「こりゃ尋常じゃないな」と思いました。

会社が心配になり連絡をしようと試みたのですが、もちろん携帯はつながらず、こういう時こそアナログ電話だ!と思いつつも、通電していないと使えない電話機であることが発覚…30分後位に3Gが復活したので、唯一社内でTwitterをやっている方と連絡が取れ、皆はひとまず無事らしい、という事が確認出来ました。

自宅にはテレビがないのですが、そもそも停電しているので見る事が出来ません。幸いにも、iPod touch用 ワンセグチューナーがあったので、これでNHKを見ると津波に襲われる東北の光景が…

自宅近くの川も津波の影響で逆流していたり、コンビニが非常用電源でレジを稼働させてがんばって営業していたりと、これは相当大きい災害だ、という事がじわじわ分かってきました。その日は停電もさっぱり解消せず、暗闇の中、キャンプ用のランタンをつけて夕食をとりました。

週明けはJRが動かなくて出勤出来ず。でも息子は大喜びで一日遊んで攻撃に出会い、別の意味でヘトヘトに。でも、父親的にはじっくり遊べた事がいろんな事を考えさせられる良いきっかけにもなりました。

次の日はなんとか出勤出来ましたが、社内のサーバー達が心配でした。それらには、ソースコードを保管しているSubversionのリポジトリやRedmine、Wikiなどの開発プロジェクト管理、他部署とデータをやり取りする為のファイルサーバーなどなど、壊れるととてつもなく困る重要なものばかりです。

もちろん、バックアップの体制は作ってありましたが、(過去にCVS、Subversionのリポジトリをぶっ飛ばした経験ありw)恥ずかしながら弊社は最小限の設備でやっておりますので、結構不安でした。中でも重要なソースコードは二重にバックアップをしていましたが、その二次バックアップ先である市販のRAID付きNASが華麗にラックから落下しており、こりゃマジでディザスタリカバリだな、と心に誓いました。(幸い中身は無事でしたが、外装には左写真のような傷が。)

この手のインフラ仕事だと、通常はある程度社内的な根回しをしてから実務の合間を縫って作業を行うのですが、今回ばかりは余震も続き、停電の問題もあったので時間が勿体なく、とにかくすぐにやる事を心がけ、問題ない所から順次クラウドに逃がしました。使ったクラウドはもちろんAWS(Amazon Web Services)です。

やった事
まず、EC2インスタンスを一つ立てました。リージョンは少し考えましたが、ここはあえて東京を選びました。それじゃ意味ないかも?とも思いましたけど、国内からアクセスしやすいシンガポールも米国西海岸もよく地震の起きる地域ですので、ここはAWSを信頼しました。そのかわり、バックアップを米国東海岸のS3に置いています。

また、外部に出してはならない重要なデータですので、セキュリティグループは慎重に設定します。ひとまず現段階では社内からのみSSHとSSLが通信出来る状態にしておきました。インスタンスはsmallインスタンスが1つです。(節電のため、と言っておきますw)
AMIはこの際Amazon Linuxを、とも思いましたが、時間の節約の為にも使い慣れているUbuntuをチョイスしました。

以下、かいつまんでやった事を書いておきます。結局は普通の物理サーバーと同じ手順です。

Subversionの移行作業
  1. 【社内】svndumpでダンプデータを取り、EC2へコピーします。
    svnadmin dump /path/to/repos | gzip > svndump.all.gz
    scp -i hoge.pem svndump.all.gz ubuntu@ec2-xxx-xxx-xxx-xxx.ap-northeast-1.compute.amazonaws.com:/tmp
  2. 【EC2】svnリポジトリを新規作成し、そこにダンプデータを読み込み直します。
    sudo svnadmin --fs-type fsfs create /data/svn
    zcat /tmp/svndump.all.gz | sudo svnadmin load /data/svn
    
  3. 【EC2】Apacheにdav_svnを入れて、httpsでアクセス出来るように設定します。詳細は割愛。
    sudo apt-get install libapache2-svn
  4. 【社内】開発マシンに入っているチェックアウト済みのプロジェクトは、svn switch --relocateしておきます。
    svn switch --relocate OLD_REPO NEW_REPO
※ここで失敗したのが、古いSVNクライアント(1.4)から新しいSVNリポジトリにrelocateしようとした時に、"UUID mismatch" のエラーが出てしまった事です。これを回避するには、リポジトリにダンプデータをロードする際、"--force-uuid" オプションをつけると良いみたいです。現行のバージョン(1.6系)ではこの問題は発生しません。

SubversionのバックアップをS3へ
社内の体制では、svnsyncで別サーバーのリポジトリへ同期をかけるという事をやっていました。今回はやり方を変えて、svn-backup-dumpsを使ってローカルにダンプデータを累積しておきつつ、米国東海岸のS3に作った同期させる、という体制にしておきました。

ダンプデータをためるディレクトリを作成し、svn-backup-dumpsを一日一回、夜中に実行します。S3にはバックアップ専用のバケットを一つ用意し、s3cmdでローカルバックアップディレクトリの中身をsyncをするという単純なやり方です。

#ダンプデータのバックアップディレクトリ作成
mkdir /data/svn-backup

#このスクリプトを一日一回実行する
svn-backup-dumps -z -c 50 /data/svn /data/svn-backup/
s3cmd -c /path/to/s3cfg sync /data/svn-backup/ s3://US_EAST_BACKUP_BUCKET/svn-backup/

これで、めでたく米国東海岸のAWSにソースコードをバックアップする事ができます。もっと心配な方は、同時にEUにもシンガポールにも置けます。

また、データを置いてあるボリューム自身も定期的にスナップショットを取っています。こちらにそのスクリプトを置いてありますので、よろしければご覧ください。

EBS snapshotとS3を使い分ける
EBSのスナップショットは取るのも簡単、復帰するのも簡単なので非常に使い勝手が良いのですが、ボリューム丸ごとをバックアップするものなので、仮にファイルシステムそのものが壊れてしまった場合に復旧が難しくなる可能性があります。したがって、

  • EBSのスナップショットはある程度履歴を取っておく
  • DBやSubversionなど、「ダンプデータ」を取得できるようなものはS3にコピーしておく

という体制を取りました。

弊社の規模感では、このくらいで十分です。そもそもディザスタリカバリなんてクラウド以前ではちょっとした夢物語でした。今ではこんなに簡単に実現する事が出来ます。

さらにS3を使う
開発に直接的に関わる部分はこんな感じでOKなのですが、その他の重要な、しかも頭の痛い問題ととして、「ファイルサーバー」があります。弊社のケースで言うと、例えば印刷担当部署とのファイルのやり取りに使うようなもので、専門のエンジニア以外が扱えるようなツールじゃないと厳しい事になります。VPCの中にSambaのサーバーを立てて…とか、そんな余力はありません。そこでやはり出てくるのがS3です。SambaやAFPのような「ファイル共有」的な使い勝手からは少し離れてしまいますが、FTPソフトは普段使っている方たちなので、CyberduckCloudBerryであれば使えるだろうと判断しました。

その経緯は、また後日別エントリを起こします。