(」・ω・)」うー!(/・ω・)/にゃー!

Blog移行しました。

| Comments

去年ははてダもういいやと思って何となくposterousに移行してたんだけど、デザインがいまいちしっくりこなくて誰にも告知せずに書いました。

posterousにしてたのは、markdownでかけるところがいい、って言うのが大前提にあったから。 はてブの時もmarkdownのメモをそのまま張るとか良くやってたけど、レポートを他の記法に直すのは面倒なのでそこにこだわって探してました。

最近、posterousも買収されてしまったので、デザインの事もあって再度別のところに移行する事に。

octopress使ってみたらmarkdownで書けるしデザインも割ときれいだったのでこれで行く事にしました。 記事数がまだ少なかったので、中身も丸ごと移してきて、このままposterousはなかった事にします。

Mysql Casual Talks vol.3にいってきた。

| Comments

メモメモ。 全体を通して実にカジュアルだった。

山岡「どうやらみなさんは本当のカジュアルなMySQLを知らないらしい。4/19(木) 19:30に来てください。本物のカジュアルをお目にかけてみせますよ」

Decolog

  • 女子いっぱい
  • うらやm。。。

Decolog構成

  • 500強のサーバ 200以上はmysql

  • ３人で開発運用

  • AWS使ってる

なぜMySQL？

  • だいたいRDBMSでたりる。
  • 使い方がわかりやすいのがいい
  • Decologではそんな難しい事はしてない。

こんな僕でも1億枚捌けた – 30days albumインフラ成長の歴史

  • ペパボのインフラの人
    • もとレン鯖の管理者

今日話すサービス

  • 30d.jp
  • 写真保存共有サービス
  • 累計１億枚超えた
  • 202TB
  • mysqlの話は少ないです。

スキップ！！！

史上最大のピンチ

  • 急に重くなった気が
  • ぎりぎりアラートこない程度の高負荷

  • 予想外の増加ペースに。

  • 週末の増加ペースが１−２TB/day

  • appサーバとDBどちらもHWの限界に。

どうにかするために

  • apache/passengerのチューニング
  • staticファイルをnginxに。

  • DBにindexたしたけど効果なし。

  • サーバ発注したけど数週間。

  • EC2をつかおう！

  • EC2上に構成を作って、参照のみそっちに流した。
  • 子、孫スレーブをEC2上に作った

孫スレーブが必要だった理由

  • masterが限界
  • 子slaveが他の機能もになってるので、あまり負荷かけたくない。

子スレーブの作成

  • xtrabackup で作成
  • internetを通してreplするのでSSLで接続

  • 孫slaveはEBSスナップショットで。

  • これでとりあえず乗り切った

サーバが納品

  • appサーバを増強
  • したら、DBに負担がかかって応答なくなってappもサチった
  • DBも増強。
  • 平和になった

まとめ

  • パフォーマンス監視だけは忘れずに
  • SSDすごい
  • 足回りのDBは早めに。

データセンター間でMySQLをカジュアルにアップグレードしたお話

  • n0tsさん

今日の話

  • 大人の事情でDC移行
  • MySQLもupgradeしたのでその話

サービス規模

  • 広告サービス
  • X000 req/sec

構成

  • MySQL 5.0.XXを使ってた
  • 移行前後で構成は特に変えない

DC間レプリケーション

  • SSLレプリケーションなぜか失敗
  • 5.0.58 へ 5.5.Xへつなごうとしてたら失敗
  • 仕方ないので、SSHトンネルで結んだ

きりかえ

  • 両方のDCに流れても大丈夫なように構成して、DNSラウンドロビンした

  • その後、DNSラウンドロビンをやめて切り替えた。

  • なんとか問題なくversion up完了。

MySQL Casual な生活

  • hatakさん
  • コロプらの人

コロプラについて

  • コロニーな生活プラス
    • 位置情報サービスのプラットフォーム
  • ユーザ250万人
  • 月間37億PV

構成

  • CentOS 5/6
  • Java/PHP
  • MySQL 5.1/5.5
  • ほぼInnoDB
  • master / slave 1:n

mysql 5.5

  • InnoDBのパフォーマンスとutf8mb4が使いたかった。
  • どれくらい変わったのか。。。はそんなに。

メンテナンスな話

  • DBには運用が必要
  • Slaveは割と簡単に入れ替え可能

  • Masterは面倒

    • やたらとやると刺さる
    • サービス停止はそれはそれで面倒

  • よくやるのはオンラインマスタ入れ替え

  • 丸ごと同じセットを作り、ごそっと入れ替える。

    • 同じ台数だけセットが必要になるのがデメリット。

  • 注意すべきところ

    • 新Masterの方で、auto_incrementの値を増やしておく
      • 重複を防ぐため。

  • preload

    • 全件SELECTするというてもある
      • blackhole Engineを使う手も。
    • 現実に即した形でやりたい
    • tcpdump + pt-query-digest

  • 気をつけるところ

    • mk-slave-moveでつなぎ変えるとかもあり。
    • 極力新しいMasterに早く切り替えられるようにする。

チューニングな話

  • 突発的に高まる事がある

  • 最初のボトルネックはMaster DB

  • ひたすらmy.cnfを調整

    • sync_binlog = 0
    • innodb_flush_log_at_trx_commit = 0
    • innodb_support_xa = 0
    • 信頼性は落ちるので、DBの系統によって個別に調整

  • diskのマウントオプションとか

  • ライトバリアとか

  • メモリをつめるだけ詰む

  • ただ落とし穴が。。。

    • からのデータにデータセットが詰まっていくとswapが。。。

  • 本番に影響しない範囲での試行錯誤大事

障害な話

  • 未然に防ぐ事大事

  • 時々巡回してチェック

  • まずは、何が起きているか、を確認

    • error_log
    • show processlist
    • slow log
    • …

  • あるある障害

    • Range Partition作り忘れ
    • cronにしてても、移行漏れ

  • サーバに起因する障害

    • show processlist でCommitがたまってる
      • disk I/O
    • Hwレベルでの監視も必要
    • クエリが詰まる
      • indexや想定外のデータ蓄積等
    • Sleepがたまる
      • app側でささってしまってるとか。

  • いろんな視点が大事

    • サーバだけでなく、コードやサービスもみないといけない。

Forcing swap in

Swap Insanity

  • NUMAアーキテクチャによるメモリアクセスが関連してswapしちゃう

  • 複数CPUだと旨くメモリを使いきれずにswapしちゃう問題

  • mysqld_safeにパッチ

  • Masterは再起動したいけどなかなか

    • Masterきりかえすべき

  • sudo /sbin/swapoff

    • page size単位でメモリに戻される
    • 案外なんとかなっちゃっった
    • ただの一時しのぎ

なんとかKitについて

  • Maatkit

    • Percona Toolkitに組み込まれた

  • Percona Toolkit

    • Maatkit / Aspersaを継承したもの

  • pt-mext

    • show global statusをside-by-sideで表示してくれる

  • pt-online-schema-change

  • pt-stalk

    • トリガーを設定できて、thresholdをこえたものに対して発動できる

  • mk-slave-move

    • なぜかなくなってる。

レプリケーションエラーから自動で復旧

ある日起きた障害

  • slaveが全部とまった

    • MySQLのbugに起因
    • なんかいかskipしてひとまず解決
    • …またとまった

  • またskipしてなんとかしたが、見地から解決まで10分ぐらいかかる

    • これではまずい

  • mk-slave-restart

    • 特定のエラーを無限skipしてくれる
    • ただ、手動なのは変わらず

  • logmon

    • IBM性のツール
    • perl
    • エラー監視できる

  • logmonで監視して、止まったらmk-slave-restartを自動で発動

    • 実運用では、さらにIRCにも通知させた
    • 時々落ちるので、Supervisordでデーモン管理

MySQL Cluster 7.2のネタ

色々告知

  • MySQL Cluster7.2が出た

    • これはKVSだよ！

  • 沖縄に行こう！

    • 4月頭に沖縄支部ができたよ。
    • スピーカー募集

  • 北海道に行こう！

    • 6月にOSC
    • スピーカー募集

  • サンフランシスコにいこう！

    • 9月末にMySQL Connect
    • 5/6まで募集
    • スピーカー募集

  • MySQL ビギナートーク

    • 5/29にここで。
    • スピーカー募集

  • 東南アジアに行こう！

    • 社員募集中

道具を磨くことのススメ

道具を磨く

  • mymemcheck

    • 最大使用メモリを算出してくれる

  • MySQLTuner

    • もうちょっと増やした方がいいかも、とかをアドバイスしてくれる。

  • tcpdump->pt-query-digest

  • show profile

  • MySQLTranCapcha

    • まつのぶさんの。

  • tpc-c

  • facebook online schema changer tool

  • MySQL Performatnce Blog

AKBとmysql-buildの話

AKBとmysql-build

  • haruna Storage Engine

    • AKB!!

  • mysql-build

    • mysqlを手元にソース持ってきてbuildしてくれるツール
    • カジュアルに色々入れてみよう

自作MapReduceフレームワーク MyMR

PHP と MySQLでMapReduce

  • MyMR
    • MySQLに入出力する
    • コマンドラインで実行
    • PHPで書く

RailsとMySQL

RailsとMySQL

  • SET SQL_AUTO_IS_NULL = 0 , NAMES utf8を最初ん勝手に打ってる
  • mysql2は実際にはprepareが実行されない
  • 自前でエスケープしないと。
  • クエリ実行はmysql_send_query
    • mysql_real_queryではない。
    • ノンブロッキングに実行するため
    • mysql_real_queryは結果を待つ

  • transaction

    • begin - commit/rollbackになる
    • auto_commitを自動できる、とかはしない。
    • ネストした場合は自動でsavepointをうつ

  • 福岡でもmysql casualやるよ！

カジュアルなクエリ品質管理

クエリ解析

  • 増強したけどまた負荷が増えてきた

    • V時回復
    • クエリ品質を担保せねば。

  • スロークエリ解析

    • 現れだしたときにはもう。。

  • show processlist

    • 頻度で見るのはいい感じ

  • mk-query-digest

    • tcpdump
    • pcap形式で保存するとサイズが小さくすむ

続・Master n 対 Slave 1 レプリケーションの作り方

n:1 repl

  • 半年間ちゃんと動いてるよ！
  • 問題出てない！

fluentdとMySQL

Fluentd mysql

  • fluentd-plugin-mysql
    • mysql-jsonでガツんと入れてしまうw

JAWS Summit 2012 の2日目レポート

| Comments

EC2

HPC向け

  • Nehalemと同等のCPUを割り当てられるものがある。

リージョンとゾーン

  • リージョン

    • 世界で８か所
      • １か所は米国政府専用
    • どこでも自由に選んで設置できる

  • アベイラビリティゾーン

    • 同じリージョン内で
    • 同じリージョン内のゾーン同士は専用線で結ばれているので高速
    • リージョン間はインターネット

EBS

  • 外付けHTDDみたいなもの

    • AZ単位で存在する。
    • 他のインスタンスに付け替え可能
    • スナップショットをS3にバックアップ可能。そのバックアップから他のAZに作成することもできる。
      • リージョンも移動できるの？
    • 複数のEC2にアタッチすることはできない。

  • インスタンスストレージとは？

    • インスタンスに付属している。別途料金はかからない。
    • 寿命がインスタンス依存

AMI

  • EBS backed AMI

    • EBSにAMIが保存されている。
    • EC2を停止してもインスタンスデータが残るタイプ。
    • stopすると停止でき、その間は課金されない。
    • terminatすると破棄される。

  • S3 backed AMI

    • 昔からあるタイプ
    • 停止すると揮発する。

セキュリティモデル

  • 責任分担モデル。
    • 物理インスタンス・ファイアウォールはAWS側が責任を持つ
    • 個別のインスタンスにセキュリティグループ、ファイアウォールが設定できる。

TIPS

  • 故障のための設計をしておく
  • 定期的なバックアップ
  • Private IP 経由の通信を活用すると安く済む
  • EBSは1Tを選ぶと性能最大化

ELB / AutoScaling / CloudWatch

ELB

  • ソフトウェアロードバランサ

    • ELB自体がスケールアウト・スケールアップを自動で行う
    • 異なるAZをまたがって分散可能
    • ヘルスチェックあり

  • トラフィックに合わせて増減するので、IPアドレスもそれに伴って増減する。IPを指定しちゃだめ。

    • ELBにはDNS名が割り振られるので、それを使うようにすべき。
    • その名前をさらにCNAMEして使う。

  • WebSocket対応しているの？

    • 現状はサポートしていない。

  • CloudWatch との統合

    • 各所のヘルスチェックができる。

  • IPv6もサポート

  • SSL のサポート

    • ELBでSSLをひもとくことが可能
    • Cipherも選択できる。

  • セッションアフィニティもサポート

    • ELBがcookieを発行できる。
    • とはいえ、スケール性を考えると使うのはあんまりお勧めしない。

  • X-Forwarded ヘッダーもサポート

  • UDPはサポートしない

  • TIPS

    • IPアドレスはダメ絶対
    • 負荷分散は、AZ毎に均等に割り振ろうとする。
      • 性能のバランスに偏りがある場合に注意。
    • 各インスタンスのサイズ・性能は考慮されない。
    • Management Consoleではサポートされていないが、コマンドラインツールでしかサポートされていない機能もあるので注意。
    • 急激な増減がある場合は注意
      • キャパシティ判定は５分ぐらい
      • 予想できるものには、事前に準備を。
    • DNSのTTLが60秒かかるので、その辺もスケール時に注意
    • ヘルスチェックのアクセス権に注意。
    • ELBの負荷テストは要注意。ドキュメントがあるのでそれに従って。
      • 60秒でセッションを切る仕様になったりしている。

AutoScaling

  • ELBと組み合わせてよく使う。
    • マニュアル・スケジュール・ポリシーベース(CPUの使用率など) に従ってインスタンスを増減してくれる。
    • コマンドラインツールから設定する。
      • グループ単位で増減させる対象を指定する。
    • インスタンスも勝手に落ちたりするので、そうなる事を考慮して設計しておく
    • 20以上のインスタンス使いたい場合は連絡ください。

CloudWatch

  • いろんなメトリクスをグラフで見れる。
  • カスタムメトリクス(有料)も作れる。

S3

デモ

  • UpするとURLがつく
  • CloudFrontを使う使わないでURL変わる。

S3とは

  • httpsでアクセスするWebのストレージサービス
  • アクセスコントロールなどもできる。

  • 信頼性も高い。

  • バケット

    • 1アカウント最大100個

  • オブジェクト

    • 1オブジェクト5TBまで。
    • バケットごとの個数制限は無い？

コンセプト

  • 堅牢であること

    • 2006年サービス以降データロストなし
    • ３か所以上にレプリケーション
    • イレブンナイン
    • 3つ以上のDCが同時に焼失しない限りは無くならない。

  • 常に利用可能なこと

    • 99.9%のSLA
    • 計画停止なし
    • ８つのリージョンから選択可能。

  • スケールすること

    • 論理的には無限にスケール
    • 1PBになろうが保存可能
    • １つのフィルサイズは5TBまで。

  • 安全であること

    • 全てSSL通信
    • 認証・認可機能を持つ
      • ACL/ポリシーベース
      • ユーザーアクセスコントロール
    • サーバサイドでの暗号化機能もある。

  • 高速であること

    • 常に高速なレイテンシ
    • 専用線で直結も可能
      • これ詳しく聞きたいな。どういった形でのサービス提供？

  • シンプルであること

    • PUT/GET/DELETE/LIST のみ
    • データサイズも数も気にしなくてよい。
    • 様々な言語でのSDKもある。

  • 低コストであること

    • 6年間で15回値下げしてる！
    • 2012/2にまた13%値下げした。

事例として

  • Smugmug
    • プロの写真販売用サイト
    • ペタバイトのデータを保存している。

AWS自体もユーザ

  • AWSサービスの中心にS3がある。

  • リージョン間での簡単な移動ソリューションはあるか？

    • インポート/エクスポートという手はある。
    • 一回ローカルに落とす感じ。

  • ディザスタリカバリとして、東京リージョン + 他のリージョンにも保持した方がいいか？

    • そこはむしろ費用との兼ね合い。
    • 日本丸ごと潰れる心配をする感じであれば考えてもいいかも。

  • 東京リージョンのレイテンシはどれくらい？

    • 公式ではないが、10msecぐらいという感じ。
    • シンガポールだと70msec程度

CloudFormation

Amazon Simpleworkflowもおすすめ！

CloudFormation

  • デプロイと自動化を担当するサービス

  • テンプレートを元にして、AWSのEC2 / ELB / S3などを一発で各サービスを構成することができる

利用シーンと利点

  • 一度テンプレートを作成すれば、同じ構成を再現できる

    • 開発環境の構築など
    • 同じアプリでデータが異なるものなど

  • ベストプラクティスが盛り込まれたテンプレートが元から提供されている

  • 起動パラメータも渡せる

利用料金

  • このサービス自体は無料

スタック

  • リソースの集合のこと

  • スタックの単位で構築することができる。

  • スタックの構築方法

    • マネジメントコンソール
    • コマンドラインツールやSDKからも可能

テンプレート

  • サンプルでいろんなものが利用できる
  • 別途、stack作成の際に自分でuploadすることもできる。

  • S3に保存しておくことも可能。

  • JSONフォーマット

    • どのサービスもだいたいJSON
    • JSONの中にプログラミングして行くようなイメージになりそう。
    • 後で変更可能なパラメータなどを定義可能
    • 予約後などもテンプレート内で取れる
    • １つのテンプレートを複数のリージョンで使いたい場合でも、分類してキーを指定したりできる。
    • スタック構築後に知りたいアウトプットパラメータとして返す値を定義して行くことも可能。

TIPS

  • EC2必須ではない
    • DB構築だけ、オートスケールだけ、アラーム設定だけでもOK
  • 参照関係があると、依存関係とみなされる。

CloudFormer

  • テンプレート作るのしんどい

    • ひながたからつくるてもあるが。。。

  • もともと持っているシステム構成を元にテンプレートを生成するリバースエンジニアリングツール

  • 使い方

    • CloudFormerのテンプレートからスタックを作成。
    • テンプレート化したりリージョンを選んで、対象にしたいリソースにチェックを入れて生成すればできる。

  • AmazonLinuxには、cloud-init / cfnヘルパー(もしくはchef)などと組み合わせることも可能なので、セットアップも柔軟に可能！

CloudFront / Route53

CloudFront

  • 世界中に散らばったCDN
    • IPアドレスベースで一番近いところにアクセスする。
  • コミットメントなし
  • オリジンにはHTTPでアクセス

  • FLVも可能

  • 利用メリット

    • EC2向けのネットワーク課金より安い
    • エッジロケーションごとに価格は異なる
  • コミットしてもらえれば、ディスカウントもあり。

オリジンの使い分け

  • EC2を使う場合
    • 動的コンテンツ
    • Ajaxなどのクロスドメイン通信が必要なもの
  • S3を使う場合
    • 静的コンテンツ
    • FLVなど

ログの保存

  • S3に保存される

    • アクセス記録は全ロケーションから24時間以内に収集
    • とらないことも可能

  • ログの形式

    • 1hもしくは50MBで分割

注意点

  • 料金はトラフィックとリクエスト数に依存

    • HTTPSの方がちょっと高い

  • 特定のエッジロケーションだけに制限することはできない

    • 日本だけ。。。とかは無理

  • エッジロケーションを絞るのも無理。

  • 今はHTTPSではカスタムドメインが利用できない

キャッシュ制御

  • 最小時間は1h
    • 廃棄リクエストは可能だが、同時に３リクエストまで
      • 1リクエストあたり1000URLまで。

動画配信

  • ストリーミング

    • エンドユーザが視聴後にファイルが残らない
    • 部分再生の場合、再生部分のみを配送するので低料金

  • ライブストリーミング

    • FMS on AWSを購入すれば可能

Route53

  • AnyCastで一番近いロケーションのDNSにつながる
  • 4つの異なるトップドメインにドメインが登録される

とは

  • SLA 100%のサービス！！
  • 権威DNSサーバ
  • 豊富なレコードタイプ

ホストゾーン

  • ホストゾーン＝ドメインファイル

    • レコードは1000個まで。緩和可能
    • サブドメインも同一のホストゾーンにできる

  • レコードは荷重ラウンドロビンをサポート

独自のエイリアスタイプ

  • ELBのDNS名をドメインだけの形にして割り当て可能

価格

  • ホストゾーン + リクエスト数

利用方法

  • Google SpreadSheetベースで管理・設定することも可能。

FAQ

  • IPv6対応だが、IPv6で運用しているわけではない。
  • プライベートIP目的の利用は推奨していない。
  • 反映はものすごく速い。1分もかかることはない

SQS / SNS / Simpleworkflow

Simple Queue Service

  • 分散Queueサービス
  • HTTPSでキューを投げて、受信するだけ
  • システムを疎結合に分割するためのキーサービス

SQSの機能

  • 最低１度の到達保証
  • シンプルなAPI
    • HTTPSでやりとりする
  • プロダクトのインストール不要

分散キューサービス

  • 自動的に複数DC間でレプリケーションされ、メッセージロストを防ぐ
  • Persisitent Message

使い方

  • エンドポイントの作成
  • メッセージの送信
  • メッセージの受信
  • のみ

メッセージの到達保証

  • 最低１度は受信する
    • At-Latest-Once delivery
  • Visibility Timeout
    • Readerがメッセージを受信した場合に、一定期間メッセージが見えなくなる
    • メッセージは明示的に消さない限り、２週間存在し続ける。
    • 勝手に消すようなコントロールはしない
  • デメリット
    • 稀に複数回届くことがある
    • 消さないと消えない

制約

  • 順序性は保証しない
  • 保存は最大２週間
  • サイズは64KBまで
  • キュー内に入るメッセージ数は無制限
  • キュー名は80文字まで。

いつ使うか？

  • コンポーネント間の依存を疎結合にする
  • オンプレミスとのやりとり

Simple Notification Service

  • 通知サービス
  • CloudWatchとも連携
  • マルチプロトコル
  • ショートメッセージも飛ばせる(日本だと微妙)

使い方

  • トピックの作成
  • トピックの購読者を登録
  • 通知を送ると、購読者に届く

制約

  • 1アカウントあたり100トピックまで
  • メッセージは最大8KBまで

Simple Workflow Service

  • オーケストレーションをするサービス
    • 分散処理を管理する
  • 言ってみれば、オーケストラの指揮者のようなもの！
  • AWSの中だけではなく、オンプレミス / モバイルなどのコンポーネントとの連携することが可能
    • ワークフローだけAmazon側で自動化できる
  • ワークフローの階層構造も可能

構成

  • Workflow Starter
  • Workflow Worker
  • Decider

Flow Framewrok

  • Java製。SWFを使うワークフローフレームワーク
  • DSLを利用する

VPC

VPCの利用典型

  • AWS上にプライベートクラウドを構築
  • オンプレミスとのハイブリッドを実現
  • 社内インフラの一部に見える
    • ENIというMac/IPをインスタンスごとに付け替えられるようにするサービスも日本で始まった

VPCの機能

  • VPN
  • プライベートサブネットとパブリックサブネット
  • インターネットへのゲートウェイ

EC2 Dedicated Instance

  • 物理サーバを別の人と同居するのは嫌だ、という場合。
  • VPC内での専用インスタンス
    • シングルテナント保証
  • クラウドのメリットは保証

パケットの出入り管理

  • ネットワークレイヤで、INもOUTもコントロールできる
  • もちろん、インスタンス単位でセキュリティグループでもIN/OUTの両方をコントロールできる。

Amazon VPCをどう考えるか

  • これから標準になるもの
  • ネットワークを仮想化するもの
  • ネットワークのに関する要望にこたえたもの
    • IPアドレス/Macの固定
    • サブネットを使った管理

使い方

  • リージョンを選択
  • IPブロックを設定する
    • 最大16ビット
    • 節約する必要はないよｗ

Public Subnetの作成

  • VPC内にIPブロックをセ艇する

    • 最大で17ビットマスク
    • サブネット内の4IPはAWS予約
    • サブネットはAZをまたぐことはできない。
    • ELBもこのサブネット内に置かれる。

  • デフォルトでは、サブネット内での通信のみ

    • 内部でのACLはフルオープン

  • Internet Gateway の追加

    • Elastic IPつけられる。
    • In / Out のフィルタ設定が可能。S3にだけアクセスさせる、とかも可能。

  • セキュリティグループ

    • EC2で扱っているセキュリティグループとは別のもの。
    • 稼働中にインスタンスとグループを切り替え可能

VPC とEC2のインスタンスの違い

  • Dedicated Instance
  • t1.microは利用できない
  • VPC/subnetを選べる

Private Subnet

  • NATインスタンスを付与することで可能

NATインスタンスとは

  • プライベートサブネットから、インターネット接続するためのNAT

    • 実態は、AmazonLinux

  • 普通のインスタンスの起動と同じように起動することができる。

  • EIPによってpublicなIPをつける必要がある。

VPNでつなぐ

  • ハードウェアVPNを対象
  • 詳細には、BGPが喋れてIPsec AES 128bitが使えればOK

制限

  • 1つのVPNゲートウェイあたり10までの接続

そのた

  • DHCPオプションの活用

  • マルチホーム(cloudhub)

    • 拠点通信も行える

  • VPCでは特別なお金は頂いてません

    • VPNの接続設定にはちょっと費用かかるけどそれぐらい。

  • EC2にあるEBSはVPCに持っていくことはできるが、逆はできない。

Storage Gataway / Direct Connect

データを移行するような場合

  • S3に持っていくような場合には、Internet経由しかなかった
  • 次にAWS Import / Exprot サービス
  • Storage Gataway
    • 既存のデータセンタのデータをクラウドストレージに安全に統合するサービス
    • インターネット経由でアクセスするサービス
  • AWS Direct Connect (10G / 1G)
    • 直接専用線を引くサービス
    • 高スループット + 低レイテンシ

Storage Gataway

  • 仮想アプライアンス

    • VMWare ESXi 4.01 の仮想サーバ
    • どこかに置くと、iSCSI対応のストレージとして見れる。
    • そ子におかれたデータが、スケジューリングされてS3に保存される。

  • バックアップデータの保存形式はEBSスナップショット

    • そのため、AWSクラウド上でシステムリカバリも可能

  • 定期的にスナップショットバックアップをS3上に保存してくれる、という感じ？

ユースケース

  • バックアップ
  • ディザスタリカバリとBCP

詳細

  • 1ボリューム最大1TiB
  • 1ゲートウェイで最大12TiB
  • 上限申請も緩和可能
  • スナップショットの作成スケジュールを1,2,4…12時間などで設定可能

Direct Connect

  • AWS Direct Connectの物理接続

    • 相互接続ポイントを公開している
    • ポイントにサーバがあるわけではない。

  • 通常の専用線引き込みと違い、サーバの設置場所指定に依存しなくてすむ。

  • EC2/S3などとの接続

    • Public ASを使ったBGP接続を行う。
  • VPCなどはVLAN

注意

  • Public IP transitは行わない
  • リージョン毎の独立した契約

できること

  • オンプレミスとのハイブリッド環境の構築
  • 広域LANサービスの一部として使うことなども考えられる。

Direct Conect 接続のために

  • AWS Direct Connect Solution Provider
  • 諸々の手続きを肩代わりしてくれる。

物理接続

  • 1Gbps or 10Gbpsの接続口を提供
  • アベイラビリティゾーンとは独立
  • Equinixへラックを設置する必要がある
  • 終端装置を置くのが、ラック単位で契約。。。
    • Solution Providerに任せれば解決はしてくれる。

Nginx + Nagios at Debianの設置

| Comments

今回のサーバにはまだ監視を入れていなかったので、Nagiosを入れる。 例のごとくWebサーバがnginxなのだが、debianのNagiosパッケージは勝手にApacheとmod_phpを入れるので却下。

ソースからinstallして、php-fpmとfcgiwrapを使う。

nagiosユーザの準備

まずはnagios管理用のuserを作る。nginxもnagiosのあれこれをいじれるようにwww-dataユーザもグループに追加。

1
2
3

% sudo useradd nagios
% sudo usermod -a -G nagios www-data
$ sudo usermod -d /usr/local/nagios

nagiosのインストール

必要ライブラリから。 nagiosをインストールするのだが、こいつのコンパイルにはgdのheaderが推奨される。 自分の環境では、libgd2-noxpmが入っていたので、これの-devを入れた。

1

% sudo apt-get install libgd2-noxpm-dev

あとは普通に進める。coreとpluginsをいれればOKなので、本家サイトから取ってくる

1
2
3
4

% wget http://prdownloads.sourceforge.net/sourceforge/nagios/nagios-3.3.1.tar.gz
% wget http://prdownloads.sourceforge.net/sourceforge/nagiosplug/nagios-plugins-1.4.15.tar.gz
% tar xvzf nagios-3.3.1.tar.gz
% tar xvzf nagios-plugins-1.4.15.tar.gz

コンパイル。configureの際、prefixが元々/usr/local/nagiosに、userもnagiosになっているので、特に指定なしでok

1
2
3

% cd nagios
% ./configure
% make all

make allが終わると、install用の各種コマンドが表示される。 今回は、Apache用の設定とかいらないので、以下の４つ。

1
2
3
4

% sudo make install 
% sudo make install-init
% sudo make install-commandmode
% sudo make install-config

これでインストール完了。次にpluginを入れる。 configureしたときにperlがperlbrewの中の物を見ちゃってほんのり心配だったので、rootで作業に切り替えた。

1
2
3

# cd nagios-plugins-1.4.15
# ./configure
# make && make install

なお、自分がこれでstartしようとしたときには/usr/local/nagios/var/spool/checkresultsのディレクトリがなくて怒られていたので、これも作った。

1

% sudo -u nagios mkdir -p /usr/local/nagios/var/spool/checkresults

これでstart

1

% sudo /etc/init.d/nagios start

Snoopyを入れておく

なんでか、nagiosを持ってきたらMagpieRSSの中で使われているSnoopyが空でエラーをはいていたので、別途入れてやる。

1
2

% cd /usr/local/nagios/share/includes/rssextlib/
% wget -O Snoopy.class.inc http://snoopy.cvs.sourceforge.net/viewvc/snoopy/Snoopy/Snoopy.class.php

nginxの設定

PHPの実行にはphp-fpm、cgiの実行にはfcgiwrapを使う。

1
2
3

% sudo apt-get install php5-fpm fcgiwrap
% sudo /etc/init.d/php5-fpm
% sudo /etc/init.d/fcgiwrap

もしかすると、元々起動してるかも。 php-fpmはデフォルトではinet socketで9000番を使うようになっているが、個人的にunix socket経由で使いたかったので、これを変更する。

1
2

% sudo vi /etc/php/fpm/php-fpm.conf
listen = /var/run/php5-fpm.sock

あとは、site-availableに以下のような内容で作る。 ログディレクトリの作成も忘れずに。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

% sudo vi /etc/nginx/site-available/nginx

server {
    root /usr/share/nginx/www;
    index index.php index.html index.htm;

    server_name nagios.example.com;
    access_log /var/log/nginx/nagios/access.log;
    error_log  /var/log/nginx/nagios/error.log;

    location / { 
        try_files $uri $uri/ /index.php;
    }   

    location /nagios/ {
        alias /usr/local/nagios/share/;
    }   

    location ~ /nagios/(.*\.php)$ {
        alias /usr/local/nagios/share/$1;
        include /etc/nginx/fastcgi_params;
        fastcgi_pass unix:/var/run/php5-fpm.sock;
    }   

    location ~ \.cgi$ {
        root /usr/local/nagios/sbin/;
        rewrite ^/nagios/cgi-bin/(.*)\.cgi /$1.cgi break;
        include /etc/nginx/fastcgi_params;
        fastcgi_pass unix:/var/run/fcgiwrap.socket;
    }   

}

これをsite-enabledにsymlinkを張って、nginxをrestart

1

% sudo /etc/init.d/nginx restart

以上で完了。

AsakusaSatellite を Unicorn で使ってみる

| Comments

ちょっと話題にあがっていたAsakusaSatelliteというのが、自分でも作りたいと思っていた物に近くてすごく便利そうだったので、入れてみた。

例のごとく、systemにinstallする形にしたので、rvmの変な影響を受けないようにrootで操作。あまり好きじゃないけど仕方ない。

AsakusaSatelliteのセットアップ

Bundlerがシステムになかったのでインストール。

1

# gem install bundler --no-rdoc --no-ri

ダウンロードページからtarballを落として、適当なところに展開。 今回は、/usr/share/nginx/AsakusaSatellite に展開した。

展開したdirに移動して依存ライブラリをインストールするのだが、今回はunicornを使いたいので、付属のGemfileを編集。

1
2
3

# cd /usr/share/nginx/AsakusaSatellite
# vi Gemfile
gem 'unicorn'

とある行のコメントアウトを削除して、bundle install.

1

# bundle install --path=vendor/bundle

MongoDBの起動

元々いた。

sockyサーバの起動

thinベースのwebsocketサーバを使ってる模様。サンプルの通り起動してみる。

# bundle exec thin -R socky/config.ru -p 3002 start

AsakusaSatelliteの設定と起動

起動の前に、sockyサーバと通信するための設定として、config/message_pusher.ymlを編集して、http: と websocket:の対象サーバドメインを自分用に変更

1

# vi config/message_pusher.yml

今回はunicornを使うので、サンプルと変えて以下のように起動。

1

# bundle exec unicorn_rails -p 3000

これで無事起動。

使ってみた感想

機能的には素敵。 gyazoも自動展開するし、File APIも使えるし、syntax highlightも効くし、redmine連携も良い。

ただ、いかんせん重い。unicornですら重い。 chatするにはもっさりすぎるので、今はまだ常用しそうにないかな。

今後に期待です。