クラウドインフラ構築記

現在AWSの構築支援に携わっております。今注視しているのは、GKE、BigQuery、Google Dataflowなどサービスを展開しているGoolge Cloud Platformです。

2014年3月17日
から hiruta
0件のコメント

JAWS DAYS 2014に行ってきました。

3/15 (土)  JAWS DAYS 2014に参加しました。1月からJAWS-UG千葉支部のコアメンバーとなって参加になりました。また、3/16 (日)のJAWS-UG総会にも参加し、2014年JAWS-UGが進むべき方向についての議論にも参加しました。

なお、整理できたものから参加レポートを記載します。なお、内容については、随時更新しておきます。

Amazon Kinesisで広がるクラウドによるリアルタイムデータプロセッシングとその未来
大谷 晋平 ＆ 榎並 利晃 [アマゾンデータサービスジャパン株式会社]

Amazon Kinesisはフルマネージドなリアルタイムデータ処理ができる。いままでは、ストリームタイプはありませんでした。

Kinesisの仕組みは肝になるのは下記２つ

  • ストリーム　（土管をイメージ）
  • シャード　(分割した単位)

Kinesisは小さいサイズで最適化している。

Kinesisがすごいと思ったのは、Kinesisに流しているEC2インスタンスが何らかで落ちてしまった場合も、チェックポイント（フラグ）を付けておいて、EC2が再起動して、落ちてしまったところから再開することが可能。

Kinesisを使う場合、Kinesis Client Libraryを使うのがGOOD！Kinesis SDKもあるが、非現実的。

サンプルなども同封されたKinesis Connectorもあります。

クックパッドのデプロイとオートスケール
成田 一生 [クックパッド株式会社]

cookpadでは、500-700 EC2 インスタンス、50 ELB、96 のS3バケットで運用。

cookpadでは、EC2のＴａｇ（タグ）を使って、管理している。

  • Name タグ　サーバーのホスト名
  • Role タグ　インスタンスの役割
    • Role:app
  • Status タグ　バランサーに追加していいかを定義
    • Status : working  となっている場合、HA Proxy ( cookpadではELBでなくHA Proxyをロードバランサとして使用しているとのこと）に紐づける

オートスケール　Instance-hour（AWSの場合、1時間単位の課金)を最小化するのがコスト的に大事。

ELBは以下理由で使っていない。

  • 1分後に反映
  • Graceful Terminate問題
    • 10から8にAuto-Scallingした際、2インスタンスがTerminateされるのだが、ELBがTerminateされたインスタンスに振り向かれて、エラーになる問題

上記問題があり、HA Proxyを利用している。

cookpadの場合、業務時間内しかデプロイしていけない、デプロイ後1時間は待機というルールがあるので、Auto-Scallingでロックする回数をうまく調整している。

Infrastructure as Codeと組織のドキュメンテーション＋Immutable Infrastructureの事例
澤登 亨彦[HiganWorks LLC]

作成準備中

※4月に、「Chef活用ガイド」の書籍が発売される予定。ただし、入門本でなく、書籍に記載されたものをそのまま使えるものではないので注意。Chef入門本は他を参照するのがよい。

プロビジョニング＆デプロイ on AWSのキホン

吉羽 龍太郎 [アマゾンデータサービスジャパン株式会社]

アプリケションデプロイ、監視サーバーに登録も含めて、どう自動化する主眼を置いた話。
クラウドの場合、SDKでサーバーを操作できる。
コードでインフラを記載するのが、当たり前になる。コードが手順書になる。
コードだと、他のプロジェクトに再利用もできる
自動化しない
  • 手順書がメンテナンスされない
  • マニュアル作業で間違う。1,2台だったら、問題ないが、10.20台だとミスもある
  • 職人芸依存
  • リリース失敗→チェックリスト追加→チェック項目が増えていく

AWSでは、故障を前提として設計が要

  • SPOF N.G.
  • 疎結合コンポーネント
  • リブートしてもシステムに影響ない設計
  • ELBにあげられるように並列処理、マルチスレッドに対応した設計

監視についても、Auto-Scallingによって、自動で対象から外れる仕組みが必要。

監視サーバーとして、Sensu http://sensuapp.org/ について紹介されていました。

Active Directory on AWS
吉松 龍輝 & 渡邉 源太
アマゾンデータサービスジャパン株式会社

ドメインコントローラの配置パターン
  • AWSとオンプレに配置
    • FSMO をどこに配置するかがポイント 環境、ネットワークによって変わる
  • AWS上のみ配置
    • リストアに注意が必要！
AWS上に配置するドメインコントローラは、現在稼働中のADドメインのドメインコントローラで構築ことが重要。
ADの設計において
  • VPN/DirectConnect 、N/Wレイテンシー、スケジュールにかかる時間
  • サイト間複製 180分
  • サイトを分けた場合は、サイト間複製、複製トポロジが意図したもので作成されているかポイント

グローバルカタログは、Exchange Serverを構築する際必要

DNSについて

  • DC上のDNSのフォワーダーがAWSが提供するDNSを設定する ※SRVレコード
  • DHCP Options Setの利用
    • ntp-serverは空欄。時刻同期は、PDCエミュレータがドメインに展開するため。こうしないとkerberos認証に影響が出る恐れがある

リストアについて

  • iスナップショットからリストアを取った場合、USNロールバックになってしまい、すべて再構築する羽目になる恐れ。
  • ディレクトリサービス復元モード(DSRM)は、AWSでは使えない。
  • ActiveDirectoryのゴミ箱機能は有効にする（デフォルトは無効）

全台破損からのリストア

  • バックアップデータから仮DC構築
  • ntdsutil metadata clleanup ゴミ情報をきれいに削除
  • AWS上でDC構築。仮DCからデータ複製
  • FSMOを仮DCからDCに移動
  • 仮DCを降格

AWSとIAMの連携

  • SAML2.0
  • IAM Management ConsoleでRoleをADと同じ名前で作成
  • ADのアカウントでManagement Consoleすることが可能になる

CloudFrontで実現するセキュアコンテンツ配信と効果のトラッキング
北迫 清訓 ＆ 今井 雄太
[アマゾンデータサービスジャパン株式会社]

CloudFrontのSigned URLについての話。Signed URLを利用することで、期間指定で公開する等が可能になる。

  • HTTPS以外受け付けないものも可能
  • 期間を指定したURL
  • カスタムポリシー
  • ワイルドカード許可コンテンツパス（特定URLすべて使用可)

CloudFrontが実力を発揮するのは、動画配信。

そこで、HLS  Live Streaming

  • HLSの売りは、WEBサーバーがあれば配信可能
    • 元の動画をセグメンターで分割要
  • マニフェストファイルの漏洩には気をつける　（AWS encryptionを利用しているが暗号が解除される場合あり)
  • Cache-controlヘッダを調整。w-maxageを長めにして、大規模配信にも可能
  • マニフェストファイルは適時更新が要。Cloudfront Distributionは同一パスで
  • プレミアムコンテンツの保護にも利用できる

CloudFrontのレポート機能　※2/14にリリース

  • 地域別アクセス、キャッシュヒット率、トラフィックスルーピットなど
  • キャッシュヒット率は今後対応予定

Cloudfrontのログ解析を自前でも解析可能

  • S3に保存したCloudfrontのログをS3DistCopyなどでEMRで分析

JAWS DAYSでは、javascript aws sdk + DynamoDBで分析結果をグラフで表示するデモが行われました。

2014年AWSイベントスケジュール
5/14-16 Cloud Comuting Expo Tokyo
6/18-19 Cloud Days Kyushu
6/25-26 Cloud Days Nagoya
7/17-18 AWS Summit tokyo ADSJ主催
10/15-17 Cloud Days Tokyo Fall
10/30 Cloud Roadshow Sapporo ADSJ主催
11/6 Cloud Roadshow Fukuoka ADSJ主催
11/10-16 re:Invent 2014
11/25 Cloud Roadshow Nagoya ADSJ主催
12/2 Cloud Roadshow Osaka ADSJ主催
Cloud Roadshow は地方版AWS Summitとのこと。Cloud Roadshowは詳細は出ていません。やることは確定。

2014年3月9日
から hiruta
0件のコメント

DevCloud2でCloudStack環境を構築

3月6日「CloudStack Day 2014」、3月7日「第16回CloudStackユーザ会」に参加しました。CloudStack基盤を利用して、サービスを行っている事業者も、IDCフロンティア、Cloudnなどもあります。

VirtualBox 仮想アプライアンス環境「DevCloud2」を使って、CloudStack環境を構築することで、実際作業した内容になります。

まずは、http://people.apache.org/~bhaisaab/cloudstack/devcloud/devcloud2.ova　からDevCloud2仮想アプライアスをダウンロードします。

次に、DevCloud2仮想アプライアンスをVirtualBoxインポートします。

ホストオンリーアダプタ追加

DHCPサーバー
サーバー有効化　チェックをはずす

DevCloud2にプリインストールされているJavaが6なので、そのままCloudStackをビルドすると、エラーになりますので、Java7を最初にインストールします。DevCloud2はベースは、Debianを利用しています。

システムアップデート

apt-get update

make-jpkgを利用可能にするのはjava-packageをインストール。

apt-get install java-package

make-jpkgは、rootでは弾かれるので、一般ユーザを作成して実行

make-jpkg jdk-7u51-linux-i586.tar.gz

debファイルをインストール

dpkg -i oracle-j2sdk1.7_1.7.0+update51_i386.deb

Java7をデフォルトにします。

update-alternatives –config java

ここまでで、CloudStackビルドの準備は終わりです。

git リポジトリからcloudstackをクローン

git clone https://git-wip-us.apache.org/repos/asf/cloudstack.git

最新版は4.4 (?)だと、マイ環境では「Imort Error：No module named codes」で後述の基本ゾーン作成で失敗しました。

今回は、4.2-forwardのrevisionを利用しました。

git checkout -b 4.2 origin/4.2-forward

ビルドを実行。しばらく時間がかかります。

mvn -P developer,systemvm clean install

デプロイ

 mvn -P developer -pl developer,tools/devcloud -Ddeploydb

java heap sizeとかの設定を行わないと、cloudstackが起動できないので、java heap sizeの設定を行います。

export MAVEN_OPTS="-XX:+CMSClassUnloadingEnabled -XX:PermSize=256M -XX:MaxPermSize=512M -Xms512m -Xmx1024m"

cloudstackを起動します。

mvn -pl :cloud-client-ui jetty:run

管理サーバーへログインまで確認

http://192.168.10.56:8080/client/

別コンソールを開いて、必要なパッケージの導入

pip install mysql-connector-python
pip install requests

基本ゾーンの設定

mvn -P developer -pl tools/devcloud -Ddeploysvr

初期設定までは行うことができました。

2014年3月2日
から hiruta
0件のコメント

WindowsAzureとAWSのN/Wレイテンシーを比較してみました。

2/26に、WindowsAzureの国内リージョンが開設されたので、「海外リージョンに比べて、x3のレイテンシーの向上」と歌っていますが、他クラウドサービスの比較で、事実上のクライド業者の一人者になりつつあるAWSとのネットワークレイテンシーをツールを使って比較してみました。

ネットワークの帯域幅を測定するnuttcp[http://www.lcp.nrl.navy.mil/nuttcp/nuttcp.html]を使って、WindowsAzureとAWSのネットワーク帯域を調べてみました。　nuttcpは、さくらのナレッジの記事で紹介されています。

結果は。。。。

WindowsAzure(Type S/ CentOS 6.5)では、

77.0707 MB / 10.33 sec = 62.5661 Mbps 0 %TX 3 %RX 0 retrans 67.04 msRTT

10.33秒で77.0707MB転送でき、RTTが67.04との結果となりました。

一方AWS(Type m1.small / Amazon Linux )では、

81.1263 MB / 10.37 sec = 65.6427 Mbps 0 %TX 6 %RX 0 retrans 35.54 msRTT

10.37秒で81.1263MB転送でき、RTTが35.54との結果となりました。
簡単に調べた結果ですが、AWSの方がN/Wレイテンシー的には上になりました。ただ、差はほとんどないので、Azureも相当頑張っている印象。ただ、東京リージョン開設したばかりなので、利用しているユーザ数はAWS東京リージョンより少ないので、二か月後再度測ってみたいと思います。

2014年2月23日
から hiruta
0件のコメント

node.jsを使って、さくらのBase Storageにアクセスしてみました。

Node.js + AWS SDKを使って、S3に差分ファイルをアップデートし続けるnode-s3maをS3互換ストレージでも使えないか、node.jsの動作検証をさくらのBase Storageで行ってみました。

node-s3maのスライドはslideshareに公開されているので、こちらを参照ください。

※node-watchをファイルの差分チェックに使用されていますので、上記サンプルはnode-s3maが動かした後のファイルの同期に有効です。node-s3ma実行前のファイルはアップロードされません。
はじめに、node.js 、npmの環境構築から。node.js環境は、CentOS6の場合以下で一発でインストールできます。
yum install nodejs npm --enablerepo=epel

node.js用aws-sdkなどをインストール.

 npm install aws-sdk node-watch mime

var AWS = require("aws-sdk");

var config = require('./conf/config.json');

AWS.config.loadFromPath("./conf/config.json");
var s3 = new AWS.S3({endpoint: config.endpointSync});

s3.listBuckets(function(err,data){

for ( var index in data.Buckets){
 var bucket = data.Buckets[index];
 console.log("Bucklets:", bucket.Name, ' : ', bucket.CreationDate);
 }
});

アクセスキーなどの設定ファイルをjson形式で外だしすることも可能です。下記設定ファイルには、上記で使用していないプロパティもあります。


{
 "accessKeyId":"xxxxxx",
 "secretAccessKey":"yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy",
 "region":"ap-northeast1",
 "topPrefix" : "backups/",
 "endpointSync": "b.storage.sakura.ad.jp",
 "watchDir": "/var/www/html/cms/"
}

実行すると、ネームスペースが返ってくることがわかります。ネームスペース作成日時も問題なく返ってきます。


# node node-s3-sample.js
Bucklets: xxxxlog : Mon Feb 03 2014 20:18:15 GMT+0900 (JST)

Node.js用のAWS SDKは以下にサンプルが公開されています。

http://docs.aws.amazon.com/AWSJavaScriptSDK/guide/node-examples.html

2014年2月21日
から hiruta
0件のコメント

2/20 gumistudy#18　の勉強会に参加してきました。

昨日 2月20日　西新宿のgumi本社で行われた「gumi study#18」勉強会に参加してきました。

（都庁前駅A5出口から新宿中央公園を通って勉強会会場でありましたgumi本社に到着。10～15分はみておくのがいい。初台からでも距離はあまり変わりませんが、都庁前駅がオススメ）

まずは会場風景

IMAG0025

「AutoScalingを約1年運用してきました」　株式会社gumi 西村　遊様

AutoScalingを運用してみた経験の話でした。git(bootstrap用)、chef（サーバー設定)を組み合わせて、サーバーインスタンスの構築を一から構築することを避けている。

AutoScalingのパターンとして以下をあげていました。

Scaduled Scale out

トラフィック同時接続数が増加したら、インスタンスを起動し、減少したら、インスタンスを削除することをスケジュールで制御。gumiではゲームアプリなので、ユーザ層が利用する時間が異なる＝時間によって負荷も違う

Auto Healing

インスタンス数を調整するパターン。

最初は、gumiではスポットインスタンスで行っていたとのこと。

スポットインスタンスがくせ者で、スポットプライスの変動が激しくなっている。( ap-northest-1cだけが激しい。ap-norhest-1bも激しくなってきた。）オンデマンド価格の三倍に設定してみても、追いつかない。

入札価格が超えてしまい、スポットインスタンスが強制的にterminateしてしまう。最近ではスポットインスタンスでの運用をやめたとこと。

「クラメソ的 CloudFormationのススメ」 クラスメソッド　植木　和樹様

CloudForamtionの話。

利用するメリット

  • クリックで構築可能
  • 再利用可能。同じような構成だと別の案件で使っていたものをコソコソ直して、数日で提供した案件もあつたとのこと
  • 何度でも使い回せる
  • ELB、EC2の構成のシステムには最適
  • git、subverisionで変更管理

デメリット

  • jsonのクセ
  • CFnで対応できないプロパティがある
  • 対応していないAWSサービスがある。最近RedShiftがCFnに対応したなど
  • COMPLETE直前でロールバックしてしまつた

CFnを利用することで、AWSサービスの構成がよくわかるなど、学習効果がある。AWSを理解してみたい方にはオススメ。

「Chef導入後のインフラ業務あれこれ」　株式会社gumi 本間　和教

「このサーバーがだれが準備したかわからない」

「どのように準備したかわからない」

など運用に問題山積み。

運用を改善する目的で、Chefを導入。

Chef-serverを導入して、すべて解決したわけではない。

社内のChatTool、機能別ではなく、サーバー別で。

インストール手順もレシピ化。

2014年2月20日
から hiruta
0件のコメント

さくらの夕べに参加しました。

vagrant + Ansibleの構成ツールの話とか、主に帯域を食いつぶすDoSをどうさくらが対応してきたか、LT4本ほどの内容でした。

Ansible/Vargrantでアドテク環境を最速構築

(内容については後日)

大雪の影響で開催延期となりましたJAWS-UG千葉勉強会 Vol.3で発表するはずだったLTも今回初発表しました。

2014年2月15日
から hiruta
0件のコメント

本日開催予定のJAWS-UG千葉勉強会の延期

本日開催予定の交通の乱れと雪の影響からJAWS-UG千葉勉強会 Vol.3を延期することになりました。

今回初LTとして、「さくらのBase Storage v.s S3」の標題で話されて頂く予定でしたが、残念です。

JAWS-UG勉強会の代わりというわけではありませんが、2/19 (水)　新宿ロイヤルビル3Fで19:30から開催される第14回さくらの夕べのLTで話させて頂く予定です。

2014年2月6日
から hiruta
0件のコメント

さくらのBase Storageへfluentd(td-agent)を利用してnginxのログの転送に成功！

前回のブログで、fluentd(td-agent)を利用して、さくらのBase Storageへnginxのログの転送にエラーが出る件ですが、設定を試行錯誤した結果、無事転送できるようになりました。

修正したところは、fluentd起動にアクセスチェックを行わないように、check_apikey_on_startをfalseにしたところになります。

これは、IDCFの分散ストレージへのfluentd(td-agent)による転送の設定と同じでした。

fluentdの設定を一部記載しておきます。

<match nginx.access>
 type s3
aws_key_id XXXXXXX
 aws_sec_key YYYYYYYYYYYYYYYYYYYYYYYYYY
 s3_bucket sakuralog
check_apikey_on_start false
 s3_object_key_format %{path}%{time_slice}_%{index}.%{file_extension}
 s3_endpoint b.storage.sakura.ad.jp
 path logs/
 buffer_path /var/log/td-agent/s3
 flush_interval 1440m
 time_slice_format %Y%m%d-%H
</match>

ストレージ内をs3cmdで確認すると、確かに、ログが作成されていることが確認できました。


# s3cmd ls s3://sakuralog/logs/
 DIR s3://sakuralog/logs/20140204/
2014-02-06 13:08 635 s3://sakuralog/logs/20140206-04_0.gz
2014-02-06 13:08 2939 s3://sakuralog/logs/20140206-05_0.gz

相変わらず、Base Storageのコントロールパネルのオブジェクトからは確認できない。この辺りはおそらく未実装ではと予想される。

この状態でしばらく運用してみます。

2014年2月3日
から hiruta
0件のコメント

さくらのストレージサービス Base Storageを試してみました。

2/3 さくらインターネットからストレージサービス　Base Storageベータサービスが発表されました。

主な特徴として

  • S3互換ストレージ
  • 1オブジェクト最大4TBまで扱える。(S3だと5TBまで)
  • イレイジャーコーディングによるデータ保護　(S3はコピーを複数Azに作る方法とは別のようです)

まずはサインアップ

さくらインターネット会員登録

さくらの会員ＩＤをもっていれば、ログインして電話認証

さくらインターネット会員登録-1

画面に記載された電話番号に電話を掛けて、音声案内で暗証番号が読み上げられるので、上記下部部分に暗証番号を入力してＯＫ

Base Storageのページのコントロールパネルをクリック

さくらのクラウドとはコントロールパネルが異なるので注意。翌々は統一してもらいたいところ。

アカウント選択-1

アカウント選択-2

ネームスペース（S3だとBucket）を新規作成

パブリック、プライベートしか設定できず。S3ほどのアクセスポリシーの機能はなさそう。

作成 ネームスペース

管理 ネームスペース

アクセストークンのユーザ名が、AWSだとアクセスキー、トークンが、シークレットキーに相当します。

ここ　に記載されている通りで、s3cmdでストレージへのアクセスは成功しました。

s3cmd lsでは表示されるのに、コントロールパネルの一覧にはなにも表示されない症状が表示されてしまいます。

次に、fluentd(td-agent)のs3-pluginをさくらのBase Storageに振り向けてみた。
aws_key_id、aws_sec_key、s3_bucket、s3_endpoint を変更。
SSLのワイルドカードSSLが「*.storage.sakura.ad.jp」なので、「s.b.storage.sakura.ad.jp」だとSSLでエラーが起きているようにみられる。td-agentが出力したエラーは下記となります。

2014-02-03 20:57:40 +0900 [error]: unexpected error error_class=OpenSSL::SSL::SSLError error=#<OpenSSL::SSL::SSLError: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed>

2014年1月31日
から hiruta
0件のコメント

2月参加予定の勉強会

2月参加予定の勉強会（セミナー）です。

2/4  AWSクラウドで安全なWebシステムを実現     「Deep Security＆InfoCage SiteShellハンズオンセミナー」　申し込みサイト
2/4  第4回 OSS運用管理勉強会　申し込みサイト
2/15 JAWS-UG 千葉支部 Vol.3 -AWSスタートアップあるある  申し込みサイト
2/19 第4回さくらの夕べ　申し込みサイト
2/20 gumiStudy #18　申し込みサイト

勉強会（セミナー)参加レポートは後日ブログにアップします。