「第8回 AWS User Group - Japan 東京勉強会」へ行ってきました

AWS Event

jaws-ug東京の第8回勉強会へ行ってきました。備忘メモをupしておきます。

# 間違いとか、この話は消せとか、もしありましたら、コメントやtwitterでご連絡ください。

『AWSアップデート』Amazon Data Services Japan 玉川さん

前回の勉強会から今日までの振り返り。

  • 3月3æ—¥: 東京リージョンスタート
  • 3月11日以降: 災害復興支援
    • ダウンしたサーバや、スケールが必要なサービスを、50人以上のメンバーがサポート
  • 4月6æ—¥: アドバンテージセミナー

いろいろなことがあった2ヶ月だったようです。

AWS勉強会でのLT

ここ1、2ヶ月の間に、全国10都市で勉強会が開催されたそうです。その中から玉川さんの印象に残ったLTとして、2つ（3つ?）が紹介されました。

  • AWS SDKのデモのLT（片山さん）
  • CloudFormation関連
    • 複合システムを簡単に作るためにJSONテンプレートを提供するサービス。WordPress、Redmine、Tracなどのセットがある。
    • "お金のかからないWordPressテンプレート"のLT（山本さん）
    • 人間CloudFormationのLT（得上さん）
      • LTの5分の間に、CloudFormationのWordPressセットを使えばできることを手動で実現する
      • 大阪では失敗!
AWS vs. 人間

今回、人間CloudFormationのリベンジということで、玉川さんがCloudFormation、得上さんが手動で、Wordpressの立ち上げ勝負が行われ、盛り上がりました。得上さんがリアルタイムにApache、MySQL、PHPをyum installして、WordPressのユーザを猛スピードで作成される様子は、カッコよくて、圧巻でしたが。。。結局、CloudFormationが約1分で立ち上げ完了して勝利し、AWSのベンリさを見せつけられた結果になりました。;-)

CloudFormationのセットは、ミドルウェアをインストール済みのモノと、Chefなどで落としてくる仕組みを組み込んだモノの2種類があるそうです。

AWSサービスのアップデートまとめ
  • VPCの機能拡張
    • インターネットに出られるゲートウェイの追加
    • サブネット間のNATの追加
  • Dedicated Instance（物理サーバ占有）
  • 東京リージョンでのElastic MapReduce
  • ライブストリーミングテンプレート
    • Adobe FMSã‚’EC2に月額5$で立てられる。CloudFrontでストリーミング。
EBSネットワーク障害の件

原因や回避策は、現在も調査中のため、改めて発表されるとのことでした（c.f. Service Health Dashboard）

ゲストトーク『Oracle on EC2でマルチサイト運用』Oracle 中嶋（[twitter:@nkjm]）さん

「ディザスタリカバリは、災害が起こる可能性に対して、かける投資が大きすぎると判断され、これまであまり進んでいなかったソリューションです。しかし、震災後、リアルな課題として認識されるようになりました」・・・とのことで、Oracle製品を活用したデザスタ対応のご紹介でした。

  • データ同期
    • あらかじめデータを同期しておき、差分更新する
    • Oracle Data Guardでできること
      • DBへの更新要求があれば、更新ログをバックアップサイトに転送し、同時更新する
      • 同期の完全性とパフォーマンスはトレードオフの関係。完全同期と非同期のモードがある
  • 切り替え
    • ソフトウェアによって、バックアップサイトへの接続に切り替える
    • Oracle Data Guardでできること
      • メインサイトが復帰したら、戻すことも可能。つまり、稼動させるサイトを選べる
  • 仮想サイト ＜＜新しい考え方
    • AWSを使うことで、バックアップサイト構築をクリックひとつで出来るようになった
    • デザスタ対応のために必要なハードウェアへの投資は、ゼロになった
Oracle Data Guardのデモ

東京、川崎、バージニアでレプリケーションをする構成で、秒間何件のデータを投入できるかを見せてくださいました。

完全同期の場合、約70件/秒のようです。3200件程度を投入するのに、25秒かかっていました。また、バージニアのサイトをシャットダウンして、東京と川崎だけで同期を取ると、2秒強で投入完了していました。

レプリケーション先が増減しても、スループットは変わりませんが、やはりレスポンスタイムの差が大きいようです。東京リージョンへの接続は、こういう場面でも、体感できるほど速いですね。

ゲストトーク『Amazon VPC検証結果』富士ソフト 飯尾さん

AWS事業を企画するお仕事をされている飯尾さんによるご発表でした。

VPCにまつわるユーザの声
  • データは自分のところにおきたい
    • セキュリティ、法律が心配
    • 連携する他システムがオンプレミスにある
  • クラウドへの移行は段階的に少しずつやりたい
  • 困ったときだけ使いたい
    • 処理量が足りないときだけ使いたい
    • 購入してしまったシステム資産が償却されるまでは物理サーバも使いたい
VPN接続のパターン
  • DBだけオンプレミスに配置
  • AWSとオンプレミスの両方にシステムを置いて負荷分散
  • AWS障害時、つまりオンプレミスのみの構成
  • オンプレミス側の障害時、つまりAWSのみの構成

従来は、「DBは手元（オンプレミス）に」という考え方だったが、最近では「DBだけパブリッククラウドに置きたい」というお客様も増えているとのこと。システムがダウンしても、データさえ無事であれば復旧できる場合が多いためだそうです。

# 意外でしたが、VPCならその需要は高いかも?と思いました。

ルーター検証

飯尾さんたちが選んだルーターの中から、良かったものを教えてくださいました。高いルーターを使いたくない、Amazon推奨製品以外の手持ちのルーターを活用したい、という背景で選ばれたものということです。

  • Juniper SSG-5-SB
  • Barracuda Load Balancer Model 340
    • 設定がGUIでできる点、30日の無償試用期間がポイント

実際に接続テストをしたところ、一度失敗したものの、L4スイッチのDSR（Direct Server Return）構成にするのをやめたら、成功したとのことでした。DSRは、帰りの接続がLBを通らないため、LBの負荷軽減に役立つが、VPN接続との相性が良くない(?)そうです。

また、セキュリティ、速さ、柔軟性が検証ポイントということで、FTPのGet/Putコマンドで50MBのファイルを取得する速さの比較や、ApacheBenchでの負荷テストをした結果を公開されていました。

Amazonさんへの要望
  • VPCの中でスケールしたい
  • VPC：オンプレ＝1：Nの構成を可能にして欲しい
  • N:N構成をソフトウェアで実現して欲しい
  • VPN接続自体の二重化をしたい
  • アクセスログとりたい（できればVPCのゲートウェイで）

# 同じ検証をする側の人間として、参考になりました。このあたりを考慮して組んだり、代替手段を探したりしないといけないということですよね。

ゲストトーク『ケータイ国盗り合戦におけるAWSクラウド化戦歴』マピオン 神守さん、須藤さん

もともとデータセンターで稼動していたケータイゲームをAWSに移行されたというお話でした。

  • 移植というシステムの並列稼動期間が必要なケースは、クラウド向き
  • 負荷をかける箇所とかかけない箇所を明示的に決めて、最適なインスタンスを選べる

といった動機が参考になりました。

以下、お話の中から抜粋したメモです。

サーバ内のソフトウェア（ライブラリ）管理方法
  • RPM化して、バージョンアップの際の管理をラクに
  • RPMはAMIに入れて、AMIをバージョン管理
    • /etc/motdにバージョン情報を記入（インスタンスにログインした時に表示されるようにされたそうです。分かりやすそう）
ネットワーク構築
  • 内部名前解決デーモンを内製
  • サーバの稼動解決デーモンを内製
    • マルチマスター/マルチスレーブ構成
    • TokyoCabinetに書いてる
キャッシュ構造
  • フロント側のApacheの共有メモリに実装

ライトニングトーク「震災支援 on AWS」サーバワークス [twitter:@ooishi]さん

サーバワークスさんのサービス「爆速ホスティング」のご紹介でした。詳細は、日経システム6月号で解説されるとのことです。

URIがRoute53に登録され、アップロードされたユーザコンテンツはEC2に入り、CloudFrontを介してダウンロードさせる仕組み。

  • なぜS3でないか
    • S3を使うとCloudFrontのキャッシュ時間がデフォルトで24時間のため

非常時にユーザが求めるシステムは、次のようなことを満たしている必要があると分かったとのことでした。

  • FTPでアップロードしたい
  • 変更したコンテンツはすぐに反映されてほしい
  • たくさんアクセスされても大丈夫でありたい
  • AWS知らない人にも操作できるものがよい

また、LTの導入で、"角刈りコボちゃん"というパンチの効いた概念が紹介されていました。ご本人を見るたびに思い出してしまいそうデス ;-)

ライトニングトーク「sinsai.infoの裏側」[twitter:@ijin]さん

被災者支援サイト・sinsai.infoの基盤に使われたAWSサービス、OSSプロダクトなどのお話でした。

システム構成図に、エクストララージサイズのインスタンスがずらりと並んでいて、驚きました。AWSさんの震災支援は素晴らしいなぁと思いました。

uploadフォルダはs3fsで、マウントが外れたら監視して自動復旧させている、というあたりのお話が面白かったです。

ライトニングトーク「CloudBerry日本語対応」李さん

CloudBerryの日本語ローカライズ版のご紹介でした。

CloudBerryを使うとうれしい点は、次のとおりとのことです。

  • S3で何ができるかが一目でわかる
  • 通常のAPIと違って改良されており、3倍くらい速い

たしかに、FTP接続、ファイルの圧縮や暗号化、マルチパート機能、マルチスレッド化、インポート/エクスポート、IAMの設定など、APIでできることは何でもできる印象でした。ウィザード形式でバックアップの設定ができるのも、芸が細かいです。

ライトニングトーク「クラウドストレージについて語る」[twitter:@FujioSUZUKI]さん

ストレージ製品・StoreSimpleのご紹介でした。

StoreSimpleは、社内の共有ファイルサーバ内のあまり使われていないファイルを選んで、パブリッククラウドへコピーしてくれる製品です。

  • 頻繁に使うファイルはSSDに
  • たまにしか使わないものはSATAに
  • もっとたまにしか使わないものはSANに
  • 年に1回使わないようなファイルはAmazonクラウドに

というように、使用頻度の高いファイルほど、高速にアクセスできるストレージに格納されます。

以下、懇親会で教えていただいた説明を補足します。

  • ファイルをストレージにコピーする判断は、どのように行われるのか?
    • StoreSimpleがファイルの最終使用日付、使用頻度などを見て判断するロジックを持っている。
  • クラウドストレージに置いてしまうと、取り出しが遅くならないのか?
    • 再び使用されたファイルは、手元に近いストレージに戻ってくる仕組みがある。
  • パブリッククラウド側のストレージは、実はS3でなくてもいけるのでは?
    • AWSのS3の他に、現時点ではAT&Tにも対応している。

クラウドの方がディスクより安い時代、という言葉が発表中にあったように、まさに今の時代に合った製品だと感じました。また、ファイルサーバの容量不足というのは、多くの会社で差し迫った問題でしょうから、ニーズも大きいですよね。

ライトニングトーク「真・SES 地震情報メール通知のバックエンドを支えたAWS」[twitter:@tottokug]さん

地震がくるたびに気象庁サイトにアクセスするご家族の便宜を図るために、地震情報をメールで送信するサービスを開発されたというお話でした。メールだけでなく、Twitterにも情報を流されているそうです。

まとめ

jawsの勉強会はこれまでUstreamで何度か見ていましたが、直接参加するのは第0回以来でした。

Amazonさんによるサービス紹介の場というよりも、AWSを利用しているユーザ企業、ベンダ、個人など様々な方が、活用方法や課題を持ち寄って共有する場だということが分かりました。自分はユーザグループといわれる集まりに参加した経験が少ないので、学ぶことが色々ありました。今後、ユーザとして混じっていけるようになりたいと思いました。

また、震災後、ダウンしそうなサービスを有志のエンジニアが次々とサポートした様子について、玉川さんが「一騎当千という感じだった」と表現されていたのが印象に残りました。こういう時に技術力を発揮できるエンジニアを尊敬します。自分は残念ながら節電と募金しかできなかったので、もっと修行しないといけません。

主催の皆さん、発表された皆さん、懇親会で色々お話ししてくださった皆さん、ありがとうございました。