クラウドインフラ構築記

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

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

Compute Engine Autoscalerを試してみました。 #gcpja

Compute Engine のオートスケール機能を使用してみました。

Compute Engine Autoscalerは、現在Limit Preview機能ですので、デフォルトでは使用することができませんので、ここからリクエストを申請する必要があります。

まずは、Autoscaler機能は現在Limit Previewですので、CLI(gcloud)初期状態はpreview機能は使えませんので以下コマンドを有効にしておきます。

 gcloud components update preview 

Replica Poolファイルを作成します。AWSでいうLaunch Configurationに相当すると思われます。

 vi replica.template 
{ "template": {
    "vmParams": {
      "machineType": "n1-standard-1",
      "baseInstanceName": "my-replica",
      "disksToCreate": [{
        "boot": "true",
        "initializeParams": {
          "sourceImage": "https://www.googleapis.com/compute/v1/projects/centos-
cloud/global/images/centos-7-v20140903",
          "diskSizeGb": "10"
         }
       }],
     "networkInterfaces": [{
       "network": "default",
       "accessConfigs": [{
         "type": "ONE_TO_ONE_NAT",
         "name": "External NAT"
       }]
     }]
   }
  }
}

上記で作成したReplica Pool configでReplica Poolを作成します。

gcloud preview replica-pools --zone asia-east1-a create --size 1 --template replica.template asia-east1a-pool
Replica pool asia-east1a-pool is being created.

replia数を最小値、最大値を1にしてオートスケールの設定をします。

gcloud preview autoscaler --zone asia-east1-a create aisa-east-aurtoscaler --max-num-replicas 1 --min-num-replicas 1 --target-cpu-utilization 0.6 --target https://www.googleapis.com/replicapool/v1beta1/projects/skillful-fx-531/zones/asia-east1-a/pools/asia-east1a-pool

VMインスタンスが起動することが確認できます。そこで、replica数の最小値、最大値を2にしてみます。時間をたたずにもう1つ VMインスタンスが起動できることが確認できます。Replica数を2から1にしても、1 VMインスタンスがterminateされます。

gcloud preview autoscaler --zone asia-east1-a update aisa-east-aurtoscaler  --target https://www.googleapis.com/replicapool/v1beta1/projects/skillful-fx-531/zones/asia-east1-a/pools/asia-east1a-pool --max-num-replicas 2 --min-num-replicas 2

ただ、Replica数を0にすることはできないようです。Autoscalerを発動しないようにしておくことはできなそう。

gcloud preview autoscaler --zone asia-east1-a update aisa-east-aurtoscaler  --target https://www.googleapis.com/replicapool/v1beta1/projects/skillful-fx-531/zones/asia-east1-a/pools/asia-east1a-pool --max-num-replicas 0 --min-num-replicas 0
<pre>{
 "error": {
  "errors": [
   {
    "domain": "global",
    "reason": "required",
    "message": "Required field not specified: autoscaling_policy.max_num_replicas."
   }
  ],
  "code": 400,
  "message": "Required field not specified: autoscaling_policy.max_num_replicas."
 }
}

SSD Persistent diskに対応していないゾーンで、disk typeにSSD diskを指定するとエラーになります。SSD Persistent diskに対応していないゾーンは、us-central1-aになります。

VMインスタンスを障害をみたてて、「nmcli c down eth0」でインスタンスに接続できない状況を発生させて、自動復旧できるか試してみました。

が、自動復旧されない。Replica PoolにHealthChecksがある。→ここ

screencapture-developers-google-com-compute-docs-replica-pool-v1beta1-pools

使おうとすると、Unknown field nameとなる。???

 

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

第4回 コンテナ型仮想化の情報交換会@東京に参加しました。 #lxcjp

昨日 niftyセミナールームで行われた第4回 コンテナ型仮想化の情報交換会@東京に参加しました。

コンテナ技術についてインプットが得られた一日でした。

Cgroupあれこれ

コンテナのリソース管理のキモのCgroupについての話でした。

dockerなどのコンテナではコンテナごとにリソース制御が重要

※AmazonLinux 2013.02、t2.microでリソース Limitを試してみました。

sudo yum install libcgroup

リソース Limitを以下のファイルに記載して、cgconfigサービスを再起動します。CPUをMax 25%に制限する設定になります。

vi /etc/cgconfig.conf
group limittest {
 cpu {
   cpu.cfs_quota_us  = 250000;
   cpu.cfs_period_us = 1000000;
 }
 cpuacct {
 }
}

リミッターをかけて、perlbrewのビルドを実施したコマンドになります。

time cgexec -g cpu:limittest /root/perl5/perlbrew/bin/perlbrew install perl-5.18.2

real 44m10.634s
user 9m5.304s
sys 0m29.512s

Using LXC on Production

mixiがLXCをProduction環境(本番環境)に導入した話

まずは、KVMで仮想環境を構築

が、ディスクIO、ディスク容量を多く消費、BIOS依存(IntelVT/AMD-V)などあった。

次に、OpenStack

scriptを使って構築が楽に

いよいよLXC

2013当時はまだ0.X 2014-02にLXC 1.0がリリースされるが、待てないので、0.9で検証開始

Dockerの簡易版といえるmixi運用に必要な機能に絞って独自LXCラッパーtrailerを開発

コンテナ系はCPU他リソースを共有するので、リソース管理が重要

ファイルディスクリプタ、カーネルパラメータのチューニングが必須 ここ にLXCチューニングについて詳しく書かれています。

CoreOSでDockerクラスタリング

dockerに最適されたCoreOSについての話

コア部分にはユーザ側でアップデートはできない(OSアップデートは勝手にやってくれる)、追加でアプリケーションを入れることができないので、docker経由でアプリケーションを入れる必要があります。

dockerなどはデータの永続化が難しいので、RDBとかは外部ディスクに保存することが必要。(RDS、Goole Cloud SQLを利用するのもあり)

GCE上で、CoreOSのVMを複数起動させて、Failoverのデモ(当日はうまいかなったようですが)

後日試してみようと思いますので、近日アップデートします。

コンテナ?これfreebsdでもできるよ

FreeBSDのjailについて

Oracle Solaris コンテナ技術

Solarisコンテナ技術である Oracle Solaris Zoneについて

FreeBSDのjailに実装的に似ている

LXC最新情報

共通で話されたことが、リソース管理の重要性がありました。

2014年8月16日
から hiruta
0件のコメント

8/15 SendGrid nightに初参加しました。 #eytokyo #SendGrid_JP

昨日8/15 Engine yardで行われたSendGrid nightに参加しました。

  • 構造計画研究所 中井勘介さんによるSendGrid入門

SendGridは決済とかトランザクションメールの処理が得意

ユーザ登録で空メールによる登録を行っているサイトも多々見受けられますが、これにもSendGridのWebhookで実現が可能

Webhookは無料プランでも使えてしまう。無料でもかなり遊べる印象

ruby、php、node.js等のライブラリも充実している

使い方によっては、停止措置を受けてしまうので、使う場合は、ほどほどに

あとは、SendGridのUpdateについて

      • トランザクションメールの複数テンプレート対応
      • SendGridから相手サーバーの間の通信の暗号化(TLS)
        • 本当に暗号化しているかは現状ログで確認するしかない。受け手のヘッダをみればわかるが。
      • sendwithusの紹介
      • クリックトラッキングの中間処理でHTTPプロトコルで通信していたのをHTTPS化
  • Ken Apple氏によるCode workshopのデモ、EventKitのダウンロードからインストールまでのデモ
    • Code workshopによるフォームでパラメータを与えれば、curl、phpコードを出力してくれるデモ
    • ウォームアップ
      • 最初はウォームアップ済IPからメール送信する割合が95%を少しずつ固定IPで送信する割合を増やす
    • SendGridの情報集約ツールEventKitのインストールから実際の動作までのデモ
      • sqliteをバックエンドで利用
        • 少々修正すればMySQLとかにもストアできるようです
      • 検索ワードは現状1バイト文字に限る。(日本語は非対応)

ここからLT

  • 株式会社FLECT 小西さんによるSendGridサンプルの紹介

  •  クラスメソッド 大瀧さんによるLT
    • Amazon SES
      • 共有IPを使っているため、IPがBlockListに入っていてメールがブロックされている場合あり
      • SES自体グローバルのサービスのため、ガラケーとかの日本独自のサービスには非対応
    • SendGridとの使い分けは必要か。

2014年8月12日
から hiruta
0件のコメント

IDCFクラウド試用してみました。 #idcfrontier

JAWS-UGさいたまの勉強会かどうかでアンケートに、「IDCFクラウド30日無料トライアル希望」のような項目がありましたので、チェックしたところ、1週間ほど前に、メールで無料クーポンコードが送られてきました。

アカウント作成編

トライアルでも登録の際、認証があります。電話認証&国際SNSで行うことができますが、電話認証ネガティブなEnglishなので、聞き間違うことがある。また、国際SNSですが、レスポンスが若干遅かった。

仮想マシン起動

CentOS6.5を使用してみました。

初期起動時は時間がかかる印象。二度目以降は速いようです。SELinuxはデフォルトで無効になっています。

仮想マシンを作るとグローバルIPアドレスが付与されますが、ポートフォワード設定を行わないと、仮想マシンにSSH接続も行えない。

AWSのように、public IP付与するようにすると、仮想マシンに接続できると望ましい。

ディスクパフォーマンス

ディスクはかなり高速な部類。

CPU 「S4 ( 1CPU / 4GB RAM )」※AWSだとm3.medium相当。
メモリ CentOS6.5

# hdparm -t /dev/sda1

/dev/sda1:
Timing buffered disk reads: 348 MB in 3.00 seconds = 115.96 MB/sec
# hdparm -t /dev/sda1

/dev/sda1:
Timing buffered disk reads: 468 MB in 3.01 seconds = 155.68 MB/sec
# hdparm -t /dev/sda1

/dev/sda1:
Timing buffered disk reads: 516 MB in 3.01 seconds = 171.30 MB/se


ファイアウォール

ポートベースで設定が行う。SSH、RDP、HTTP、HTTPSとかよく使うプロトコルについては簡易設定のような機能がほしいところ。

 

 

2014年7月27日
から hiruta
0件のコメント

先日7/26 松戸市民会館で、JAWS-UG千葉 第4回勉強会 「AWS運用縛り」が開催されました。 #jawsug #chibadan

先日7/26 松戸市民会館で、JAWS-UG千葉 第4回勉強会 「AWS運用縛り」が開催されました。

 

  • クラメソ保守運用担当からみたAWS使っててよかったことtogetter まとめ dlvr.it/6R8T3C

クラスメソッド株式会社 植木 和樹さん@czkuk

AWSの運用をどうすべきかのお話。(AWSサポートはすばらしい。「Business サポート」以上)

Management Consoleより、aws-cliの方が手順が作成しやすい。

AWS運用チェックリストもオススメ。ベース文書は英語ですが(Operational Checklists for AWS)、ポイントをhttp://dev.classmethod.jp/cloud/aws/aws-operational-checklist/ にまとめれています。

  • エンジニア3人で支える月間10億PV

株式会社DoBoken 磯部 有司さん

ZenClerk http://zenclerk.com/  の運用上の工夫

ZenClerk アーキテクチャ

スポットインスタンスを、100→200と一気に増やすと、全体(リージョン)の相場上がって、全部死( terminate )

開発ツール Slack

Redmineは入力項目多いことで使用していないとこと

監視は、MongoDBの健康状態を第一に考えている (MongoHQ )

  • ドキュメントを書こう! 運用自動化時代のドキュメンテーション

運用設計ラボ合同会社 波田野 裕一さん @tcsh

AWS Summit  クラウド時代の運用 パネルで視聴しましたが、自動化の前に、構造化設計Why ( ドキュメント)が重要

ドキュメントツール SPHINKの紹介

※ JAWS-UG CLI 支部( JAWS-UG初の専門支部立ち上げ)

facebook https://www.facebook.com/groups/jaswug.cli/

  • 「AWSを含めたハイブリッド環境の監視の実現 ~Zabbixのクラウド対応モジュールHyClops~」

TIS 株式会社 池田 大輔さん@ike_dai

ログとかは長期の傾向を見る必要があるが、CloudWatchは二週間分しか保存されない。

そこで、Zabbixでの監視

HyClops for Zabbix

 HyClops for ZabbixでCloudWatch連携できているのは課金情報のみ。EC2、ELB、RDSについては今後対応予定とのこと

最近リリースされたCloudWatch Logsは、ログのタイムスタンプは注意(ログのタイムスタンプはdatetime_formatで指定)

 

また、LT 4本も発表されました。

  • 「LEGOマインドストームでシステム監視」

株式会社Syun 高松 基広さん @TadaKazegaFuite

 

  • 「NO MONITORING NO LIFE – さぁ、監視を始めよう on AWS」

クリエーションライン株式会社 前佛 さん @zembutsu

  AWS × Muninの話

  • 「リアルタイムログ解析システムの裏側」

株式会社ナレッジコミュニケーション 奥沢 さん

Fluentd を、Kinesisに置き換えた話

Kinesisに置き換えたことで、WEBサーバーが増えても(スケールアウト)しても、構成変更が必要ない。

KinesisはRedShiftと相性がいいので、ログ分析には最適。先日東京リージョンでもKinesis対応したので、Kinesisの利用事例が増えるのではと予想される。

  • 「AWSサミット東京1日目のパネル<<クラウド時代の運用>>振り返り」

アマゾン データ サービス ジャパン株式会社 荒木 さん @ar1

 

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

AWS Summit 2014 参加レポート #awssummit

7/17、7/18 AWS Summit 2014に参加してきました。JAWS-UG Night Partyその後の二次会まで23時ごろまで、AWSなどクラウドの話で終日盛り上がりました。受講したセッションについて、ポイントを記載します。参加したセッションは主に、Enterprise、Techlogyセッションになります。

  • TE-04 The philosophy & design on AWS OpsWorks


OpsWorksの沿革から、仕組み、バックで使用されているChef、デモがありました。OpsWorksはテスト、開発環境をスピーディに構築できる。
ビルドインサポートとして、HAProxy、Node.js、Gangliaなどがある

CloudFormationとの組み合わせ利用ももちろんOK
OpsworksはStage、開発環境構築等に最適

  • TE-05 クラウド時代の運用


システムのライフサイクルで一番長いフィーズだが運用の位置がここまで評価されていない
レガシー運用、DevOpsでの運用されている方々の話
自動化がブームだが、基本はドキュメントが大事。(Chefレシピ、JSONもドキュメントの一部)

 

  • TE-06 エンタープライズ向けAWSクラウドデザインパターンのご紹介(ネットワーク)

VPCの留意事項
VPCトは16bitが作成できるCIDR。VPCのCIDRは変更できないので、最初に考慮が必要。
※なるべきCIDRは取得できる限り丸ごと取っておくことが望ましい。
Network ACLsの使い方
共通ポリシなど最小限のポリシを適用しておくのがよい。e.x. 共通で制限できる通信
NATの冗長化、スケールアップ
外向けプロキシ
AZを使った冗長化
CDP候補? (システム再現パターン、インターネットサービスパターン、内部向けアプリケーションパターン、バックホームパターン)

  • EA-07 AWS上のシステムはこう作る!InfrastructureAsCode/ImmutableInfrastructureを実践した構築自動化とHinemosで実現するクラウド運用自動化

AWSでサーバー調達等は短くなったが、ミドル、検証テストは時間がかかる

自動化は必要

自動化する上のポイント
自動化コードに問題があった場合の対応
IMAG0154

自動化コード規約の必要性

HinemosはAWS APIとの連携 ※IAM Role使えるかはブースの担当者も???

Hinemos HA on AWS 9月リリース予定
※有償とのこと 料金は未定

IMAG0156

IMAG0156

  • TC-09 AutoScale×ゲーム ~運用効率化への取り組み~

AWS導入に至った背景

オンプレだと

休日夜間で即対応不可能 30分~2時間
機会損失、運用コスト

そこで、AWS導入

サーバー構築自動化が必要 (AutoScalling)

機能を詰め込んだAMIを検討したが、サーバーごとに設定が異なるため、その分AMIが必要。管理が煩雑
Chef receipeで検討。34項目が必要だが、サーバ構築に20分
Chef receipeの短縮のため、共通設定は一部AMIを利用することにした。

価格問題

オンデマンドだと価格が
リザーブドも検討したが、インスタンス変更の制約等がある
スポットインスタンス

スポットインスタンスは需要と供給で価格が変わる

スポットインスタンスを入札の変動状況を監視(Zabbix)
入札額が価格を下回ることでサーバー起動しない問題

LaunchConfigurationを複数用意することでConfig切替

アバター合成サーバーの負荷対策

S3マウントだと片系に集中、CPU負荷
GlasterFS

冗長化
ホストベースPeerによるノード追加

ノード生死の自動判別

Serfでノード追加制御(ホストの名前解決)

ログ収集はFluentd、ただし、Fluentd中継サーバーで効率化

  • ・EA-09 AWSのスケーラビリティを最大限に活用したKOSEの店頭支援システム「K-PAD」のご紹介

AWS導入に至った経由(震災の影響)
顧客情報等個人情報を扱うので、セキュリティを最重要視

店舗、オンプレ、AWSはDirectConnect及びキャリアIP-VPNでセキュア接続な環境を確保。

IMAG0160

店舗端末(iPad)にはデータレス、Radis/個体認証を組み合わせている
随時店舗への導入が随時のため、サーバーサイジング
インスタンスタイプの随時変更

IMAG0161

  • EA-10 クラウドで実現する次世代マーケティングとは?

すかいらーく、無印食品、あきんどスシローのクラウドを使用した利用、効果
社内をどう納得させたか

 展示ブースにてほぼブースを回りましたが、以前のプレスリリース等から説明員から説明を頂きました。

  • VPC専用SIMによる閉域モバイル接続
    • SIMを使ったAWSへのセキュア接続サービス。主に営業向けサービス。タブレットでVPC専用SIMを使ってDaaSのデモをして頂きましたが、実用に耐えるレベルの体感でした。Office文書の変更も可能。タブレットサイドにはデータを残さないので、端末紛失時の対策もOK
  • 運用自動化ソフトウェア Hinemos
    • 9月ごろにAWS上のHinemos パッケージ Hinemos HA on AWSがリリース予定。※料金形態は現在検討中とのこと
  • Cloud Automator
    • EC2起動等の処理の自動化。定期的に起動させてジョブを実行するバッチに適しているのではないか。ジョブ実行後はインスタンスは捨ててしまうことで、トータルコストの低減が図られる。
  • ジョブ管理ソフトウェア WebSAM JobCenter ※参考出展
    • ブラウザ上でジョブフローを構築できる。JP1に近い印象を受けました。
  • クラウドファイルサーバスターターパック 大容量NAS Suite

Montion Board、Tableauなどビックデータ関連の展示も多く見られた。

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

クラウドを渡り歩け!さくら×ニフティ 合同ハンズオン勉強会!! に参加しました。 #ncstudy

前日AWS Summitの懇親会、二次会とかなり帰宅(0:00ごろ)が遅くなりましたが、ニフティ本社セミナールームで行われたクラウドを渡り歩け!さくら×ニフティ 合同ハンズオン勉強会!! に参加しました。

勉強会の流れは以下で進みました。

  • サーバー構築
    • さくらのクラウド、ニフティクラウドにCentOS 6.5、Ubuntu 12.04構築
  • dockerインストール
  • docker の説明
  • コンテナ構築
    • 静的コンテンツコンテナ
    • pukiwiki動的コンテナ
    • WordPressコンテナ
  • クラウド間マイグレーション
    • docker export/importで、niftyクラウドからさくらのクラウドで動作しているdockerにマイグレーション (さくらのクラウドからニフティクラウドへももちろん可)
  • ディスカッション

本ハンズオンセミナーはdockerの基盤の勉強会ではなく、dockerをどう活用するかにポイントを絞ったものになります。docker基盤については、hbstudy等で発表されたslideshareをみるのがいいかと。

実際使用したハンズオン資料は以下に公開されています。

Dockerハンズオン資料 – Qiita

Dockerは、手軽、サーバー使い捨て、クラウド間でlaaS基盤の違いを吸収してしまうすごさをもっていることを改めて実感。ベースOSがUbuntuでもCentOSでも、意識することなくコンテナを構築できる。

さくらのクラウドのアーカイブにCoreOSが対応しているとのこと。CoreOS = Docker専用の軽量Linux

centos:latestとすると、すでに、CentOS7が選択される(CentOS7てPreviewフィーズではなかったか)ので、CentOS6を使う場合は、centos:centos6とする必要がある。

クラウド間マイグレーションは、niftyクラウド、さくらのクラウドにかかわらず動作するはず(GCP、AWS) 。

ただし、IPアドレスを埋め込まれたシステムのマイグレーションは、問題が生じることがあります。例えば、WordPressコンテンツの場合、CSSとかが読み込まれなくなることがある。この点については、DNSの仕組みを組み合わせることで解決できます。

また、docker exportは、コンテナは停止状態で行う必要があります。(フラグでホットスポット状態でもエクスポートできるようになるらしいが推奨されていません。整合性を考えると当たり前か)

ディスカッション時にもでましたが、dockerは、開発、テストには向いていますが、商用運用を行っているのはGoogle位で、まだまだの感。

2014年7月13日
から hiruta
0件のコメント

Google Compute Engineのスループットを計測してみました。 #gcpja

イメージは、CentOS6(centos-6-v20140619)を、
マシンタイプは、n1-standard-1 (vCPU 1個、メモリ 3.8GB、標準永続ディスク10GB) ※m3.medium相当
インスタンスは同じネットワークに属して行いました。

  • 同一リージョン内

まず、GCEの東アジアリージョンで、iperf3を使って、スループットを計測してみました。
asia-east-1-a <-> asia-east-1-a(同一ゾーン) :1.7Gbps
asia-east-1-a <-> asia-east-1-b(異なるゾーン) :1.6Gbps

  • asia-east-1-a <-> asia-east-1-a

 

$ iperf3 -c 172.16.219.40
Connecting to host 172.16.219.40, port 5201
[  4] local 172.16.161.66 port 59195 connected to 172.16.219.40 port 5201
[ ID] Interval           Transfer     Bandwidth       Retransmits
[  4]   0.00-1.00   sec   208 MBytes  1.74 Gbits/sec    0
[  4]   1.00-2.00   sec   224 MBytes  1.88 Gbits/sec    0
[  4]   2.00-3.00   sec   222 MBytes  1.87 Gbits/sec    0
[  4]   3.00-4.00   sec   228 MBytes  1.91 Gbits/sec    0
[  4]   4.00-5.01   sec   225 MBytes  1.87 Gbits/sec    0
[  4]   5.01-6.00   sec   223 MBytes  1.88 Gbits/sec    0
[  4]   6.00-7.01   sec   229 MBytes  1.92 Gbits/sec    0
[  4]   7.01-8.00   sec   221 MBytes  1.86 Gbits/sec    0
[  4]   8.00-9.00   sec   224 MBytes  1.88 Gbits/sec    0
[  4]   9.00-10.01  sec   228 MBytes  1.90 Gbits/sec    0
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retransmits
[  4]   0.00-10.01  sec  2.18 GBytes  1.87 Gbits/sec    0         sender
[  4]   0.00-10.01  sec  2.18 GBytes  1.87 Gbits/sec              receiver

iperf Done.
  • asia-east-1-a <-> asia-east-1-b
$ iperf3 -c 172.16.96.191
Connecting to host 172.16.96.191, port 5201
[  4] local 172.16.161.66 port 46350 connected to 172.16.96.191 port 5201
[ ID] Interval           Transfer     Bandwidth       Retransmits
[  4]   0.00-1.01   sec   213 MBytes  1.77 Gbits/sec    0
[  4]   1.01-2.00   sec   216 MBytes  1.83 Gbits/sec    0
[  4]   2.00-3.00   sec   220 MBytes  1.85 Gbits/sec    0
[  4]   3.00-4.00   sec   217 MBytes  1.82 Gbits/sec    0
[  4]   4.00-5.00   sec   218 MBytes  1.82 Gbits/sec    0
[  4]   5.00-6.00   sec   210 MBytes  1.76 Gbits/sec    0
[  4]   6.00-7.00   sec   221 MBytes  1.86 Gbits/sec    0
[  4]   7.00-8.00   sec   214 MBytes  1.79 Gbits/sec    0
[  4]   8.00-9.00   sec   221 MBytes  1.86 Gbits/sec    0
[  4]   9.00-10.00  sec   222 MBytes  1.86 Gbits/sec    0
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retransmits
[  4]   0.00-10.00  sec  2.12 GBytes  1.82 Gbits/sec    0         sender
[  4]   0.00-10.00  sec  2.12 GBytes  1.82 Gbits/sec              receiver

異なるリージョン間

  • asia-east-1-a <-> us-central1-a :116Mbps

予想した通り、同一リージョンより1/10のスループットの結果となりました。

  • asia-east-1-a <-> us-central1-a

 

 iperf3 -c 172.16.125.92
Connecting to host 172.16.125.92, port 5201
[  4] local 172.16.161.66 port 49034 connected to 172.16.125.92 port 5201
[ ID] Interval           Transfer     Bandwidth       Retransmits
[  4]   0.00-1.07   sec   512 KBytes  3.91 Mbits/sec    0
[  4]   1.07-2.13   sec  5.00 MBytes  39.7 Mbits/sec    0
[  4]   2.13-3.07   sec  14.1 MBytes   125 Mbits/sec    0
[  4]   3.07-4.07   sec  17.9 MBytes   150 Mbits/sec    0
[  4]   4.07-5.07   sec  18.9 MBytes   158 Mbits/sec    0
[  4]   5.07-6.07   sec  16.8 MBytes   141 Mbits/sec    0
[  4]   6.07-7.07   sec  18.4 MBytes   154 Mbits/sec    0
[  4]   7.07-8.07   sec  17.6 MBytes   148 Mbits/sec    0
[  4]   8.07-9.07   sec  18.0 MBytes   151 Mbits/sec    0
[  4]   9.07-10.07  sec  18.0 MBytes   151 Mbits/sec    0
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retransmits
[  4]   0.00-10.07  sec   145 MBytes   121 Mbits/sec    0         sender
[  4]   0.00-10.07  sec   145 MBytes   121 Mbits/sec              receiver

iperf Done.

同一リージョンであっても、ゾーンが異なる場合、ディスクを使いまわせない

異なるリージョン、ゾーンが異なる場合でも、snapshotからディスクを作成することができます。

AWSの同一リージョン間

参考として、東京リージョン(同一ゾーン)のスループットを計測してみました。
GCEの1/3程度とGCEのネットワークの性能の良さが分かる結果となりました。

  • asia-east-1-a <-> asia-east-1-a(同一ゾーン) :310Mbps
  • ap-northeast-1b <-> ap-northeast-1b

 

$ iperf3 -c 172.16.80.190
Connecting to host 172.16.80.190, port 5201
[  4] local 172.16.80.111 port 35286 connected to 172.16.80.190 port 5201
[ ID] Interval           Transfer     Bandwidth       Retransmits
[  4]   0.00-1.00   sec   144 MBytes  1.21 Gbits/sec    0
[  4]   1.00-2.00   sec  35.6 MBytes   299 Mbits/sec    0
[  4]   2.00-3.00   sec  35.4 MBytes   297 Mbits/sec    0
[  4]   3.00-4.00   sec  35.4 MBytes   297 Mbits/sec    0
[  4]   4.00-5.00   sec  35.4 MBytes   297 Mbits/sec    0
[  4]   5.00-6.00   sec  35.4 MBytes   297 Mbits/sec    0
[  4]   6.00-7.00   sec  35.4 MBytes   297 Mbits/sec    0
[  4]   7.00-8.00   sec  35.4 MBytes   297 Mbits/sec    0
[  4]   8.00-9.00   sec  35.4 MBytes   297 Mbits/sec    0
[  4]   9.00-10.00  sec  35.4 MBytes   297 Mbits/sec    0
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retransmits
[  4]   0.00-10.00  sec   463 MBytes   388 Mbits/sec    0         sender
[  4]   0.00-10.00  sec   463 MBytes   388 Mbits/sec              receiver

iperf Done.

まとめ

  • 同一リージョン内はゾーンが異なっても、1Gbps越えのスループット
  • AWSにくらべてもかなり良好な結果

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

JAWS-UG三都物語2014に参加しました。 #jawsug #santo

7/5 大阪で行われたJAWS-UG三都物語に参加しました。

10455586_706806502726664_6270208922236699897_n

 

(写真は帰り伊丹空港で撮影したものです)

  • JAWS-UG三都物語 ( on パソナテック大阪本社)
    • Togetterまとめ 三都物語に関するツイートをまとまっています。

参加したセッション

  • 三都物語でAmazon SWFと握手! (片山暁雄)
  • OpsWorksで構築するアプリケーションデプロイ環境 (堂端翔・麻田優真)
  • 開発現場で活用するVagrant (新原雅司)
  • オンプレからAWSへの劇的ビフォーアフター (坂井学)
  • MTとAWSと萌えと (青木まゆみ)
  • AWSクラウドを使った情報共有・リモートワーク (辻義一)
  • 回転寿司をクラウドで。スシローがクラウドを選んだわけ (田中覚)

 

  • 三都物語でAmazon SWFと握手!
 SWFは、ワークフローを担当するものではなく、何かがどこまで進んでの管理、仲介役
 GUIが付いたものはではない
 状態管理とコーディネイトを管理
処理能力が上がっていかない
その処理とその処理が終わったら、次の処理に移る
ファイアウォールなどネットワーク越も可能
動画の処理を例に挙げて説明をされました。
アップロードから始まって、元のファイルを保存、サムネイルを造ったり、していく
個別の処理をプログラムを作って、サイト公開まで
 全体の処理が長くなってしまう
 性能向上 スケールアップする サーバーのスペックを上げる
 エラーでリカバリできない
という問題がある
これでは大きなサービスにする場合はまずい
処理の間にキューを挟む
 SQSの場合、エラーになった場合リトライできる
 キューに対して複数のサーバーを立てることで負荷分散
アプリケーションの冗長
順番は意識する必要がある
タスクの制御
 集中的に進捗管理をする
 指揮官みたいな人が入れて、タスクの順番をしているので、PC用、スマホ用で同時に処理をする
タスク間が疎結合になる
同時に処理を投げることもできる
タスクの順番も変える
メリットは大きい
タスクの制御がSPOF
複雑な実装が必要
タスクの制御は難しい
アプリケーションの順序をする機能を切り出し
処理終了したら。通知
処理が楽になる
状態の管理、キューに投げたりすることを分ける
 決めるところをステートレスになる
これがAmazon SWF 中間管理職的役割
SWFの利点
 データを三カ所のAZに保存
 1タスク、1アプリケーションでしか処理できない
 履歴も三ヶ月保存
 ポーリング タスクを決める人、各種タスクをファイアウォールを超えることができる
 南米にあっても、アメリカにあってもOK
SWFのワードの説明
  • ワークフロースターター
 ワークフローをキック
  • ワークフローエグゼキューション
  • タスクリスト
 タスクが入っているキュー
 キューも分けることもできる 無料ユーザ、有料ユーザを分けることもできる
SWFの利用事例 として、Sansan株式会社 名刺サービス  「Eight」
  写真を撮ったら、SWFで加工して手作業などへて、データ化
SWFを開発する上で
Flow Framework オススメ
 Java, Ruby (コード量が少ない、簡単)
スケーラブルな非同期処理が簡単に
SWF 組織をうまく使えるようになる
音系は不向き
  • OpsWorksで構築するアプリケーションデプロイ環境
自動化ソリューション
Stackは簡単にコピーすることができる
役割ごとにインスタンスを分けたもの
Chefのレシプが実行されるタイミング
 shutdown 45秒前
RDSもOpsworksで使えるようになりまいた。
負荷の閾値でもスケールアウトしたりできる
EC2でもできるが、レイヤーで分かれているので、視覚的に設定
 ※最近ではEC2でもできるようになりましたが
細かい設定はEC2が勝る。
chefのレシピの実行に時間がかかる
 Receipeを小さくしてインスタンスの準備を高速化するのがよい
Chefについて
cookbook の説明で料理本
chefの自動化できるかちゃんとできるているか不安な場合は、serverspecでコードのテスト
カスタムレシピも可能
ライフサイクルイベントのタイミングで個なるレシピを実行できる
Opsworksは、chef-soloベースなので、chef serverの機能は使えない
c3.largeでも、 初回 5分から10分かかる
  • 開発現場で活用するVagrant
vargrantを開発現場で使う上で、気をつけたいポイントについての話でした。
デモを中心に話されました。
vargrantと連携できるツールは以下いろいろあります。
 VirtualBox vmware
  aws
  chef
  puppet
  ansible
  docker
 vargrantは、連携ツールに依存。ただのコントローラー
 つまりは、仮想環境に指示を出すものです

VBoxManageを実行しているだけ
dockerはvargrantを置き換えるものではない。docker+vargrantについては以下過去発表した以下資料を参照するとよいとのこと

hostとvargurantで起動したGuestOSのフォルダを同期するSynced Folderについて。 Dropboxのイメージ
Vargrant Shareを使って、Vargrantの仮想マシンをインターネットに公開できる
Vargrant Cloudにアカウント登録は必要。
最後に言えることは、vargrant sshでログインして設定を変更することは避けるのがベスト
  • オンプレからAWSへの劇的ビフォーアフター 

iNSIGHTBOXをAWSに移行した話
http://www.slideshare.net/manabusakai/aws-before-after
データ量の増加にインフラ構築が追いつけない ディスク増やしたい ぎりぎりの状態 営業売りたがらない
インフラ要因で止めることはできない。 XX待ってとはいけない
インフラ構築
 ボトルネック HBase  複雑 サーバー増やすとスケールアウト。サーバーを増やすのがボトルネックになっていた
 ノード数が足りなくなってきた。LINEもHBase
 物理サーバーなので、サーバーの発注、設置とか二ヶ月かかってしまう
増強のために二ヶ月待っていられない
性能検証、データ移行はしっかり実施
Netflix Chaos Monkeyという 障害を仕掛けにしていくツールもあるが、これを使わず障害対処する方法を構築したとのこと
障害時は新しいサーバーを立ち上げて、サーバーの復旧を優先する
  • MTとAWSと萌えと

Movable Type + S3を使った話になります。

s3fs  +  lsyncd を使ったコンテンツをS3に同期させて、S3 ホスティングを実現したことを説明されまいた。

また、S3 へ転送させるplugin の紹介もされました。個人的にはIAM Roleに対応してくれるとなおよいが。

MTの場合、静的コンテンツを生成するので、S3と相性がいいと思われます。

http://tec.toi-planning.net/mt/amazon/mt-amazons3/

MTではないが、当ブログも、Wordpress + Nephila clavata (絡新婦) で、メディアデータは、S3への同期を実現していたりします。

  • AWSクラウドを使った情報共有・リモートワーク

 

クライアント証明書認証も、端末単位の接続もオススメ
Tsunami UDPは、リージョン間のファイル転送高速化
Workspace について
画面転送速い。DesktopアプリだとRedshiftの分析には快適で
PCoIP 暗号化Sされている
12時間ごとにS3にバックアップ

  • 回転寿司をクラウドで。スシローがクラウドを選んだわけ

ベースはWBSで放映された内容でした。

IMAG0106

 

新しい取り組みとして、Kinesisを使って、店舗のデータを取り込み、分析するシステムを構築中とのこと

IMAG0107

 

ある店舗のリアルタイムデータのデモ披露。

IMAG0109

 

将来の構成について

 

IMAG0110

この後、懇親会、LT大会などもあり、終日盛り上げって大盛況のうちに終了しました。

秋は

jaws__tohoku2014logo2

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

6/28 第4回JAWS-UGさいたま勉強会 – 「もっとクラウドを知ろう」 – に参加してきました。 #jawsug #jawsug_saitama

6/28 第4回JAWS-UGさいたま勉強会 – 「もっとクラウドを知ろう」 – に参加してきました。

勉強会前の名刺交換風景

BrMDK5qCMAABg2h

目次

  • VPC Peerring & IP in IP Tunneling (保刈さん  facebook :hokari.yutaka)
  • AWSが絶対やらない事を5つやってみた (IDCフロンティア 末留様 facebook:tatuya.suetome)
  •  「ニフティクラウド」AWSとの違いと今後の展望 (ニフティ クラウドプラットフォーム部長 佐々木様)
  • Microsoft Azure 上にある開発環境を使った node.js でのアプリケーション開発 (日本マイクロソフト エバンジェリスト 大田昌幸様 facebook:masayuki.ohta1986 )

セッション

  • VPC Peerring & IP in IP Tunneling
    • JAWS-UGさいたまメンバー 保刈さん

VPC Peeringに関する話。

現状VPC Peeringは、二段ルーティングはできないのを、カーネルにあるモジュール(ip tunel)でトンネルを作成して、1つ先のVPCへの疎通を実現している。tunelを張る前はPING疎通ができなかったのが、tunelを張ったら、疎通できるデモ実演もありました。

冗長化とか考慮されていないので、実際使う場合は、別途考慮が必要。

tunelしたことで、スループットがどの程度になるか気になるところ。

  • AWSが絶対やらない事を5つやってみた
    • IDCフロンティア 末留様

10460735_702545146486133_3128331571148801465_n

AWSで絶対やららないことを5つやってみた話。

1つめ ハイブリッド(クラウドと物理サーバを組み合わせて構成を構築できる。)

物理サーバーとはL2接続されており、ゲーム業界のお客様に好評をもらっているとのこと

2つめ プラットフォームサービス(ネイティブアプリ向けプラットフォーム)

課金、KPIレポートなどで支援し、開発工数削減が図れるサービス

3つめ NaaS ( Network as Service )

DDoS、LB、Firewall、WAFなどがオプションで即利用できる

4つめ 製版一体

想定外のトラフィックが発生し、このお客様のために、専用線10Gに接続し、裁いた例の説明

5つめ お・も・て・な・し

サポート

  •  「ニフティクラウド」AWSとの違いと今後の展望
    • ニフティ クラウドプラットフォーム部長 佐々木様

10492515_702558423151472_2285259878478383006_n

ニフティクラウドは、すべてのAWSのサービスに相応まではいかないが、代用できるサービスが揃えている。

ハイブリッド、UIの使いやすさ、AWS API互換を強調していました。

ニフティクラウド Automation AWS Opsworksと似のサービス。レシピ作成支援ツールの提供も予定していること。

ニフティクラウド Automationは、6/18正式公開。Opsworksと似ているサービス。

  • Microsoft Azure 上にある開発環境を使った node.js でのアプリケーション開発
    • (日本マイクロソフト エバンジェリスト 大田昌幸様

Azure 仮想マシン、デモ

Azure WebSites 、デモ

WEB上で開発できるVisual Studio online、オンラインとは思えないほど、動作がきびきびしている。

この後、グループに分かれてのどんなサービスが欲しい/JAWS-UGさいたまへの期待のDiscussion、懇親会に続きました。

来週は、

10368199_720325471357202_4440372875891479965_n