ただつらつらと日記が書かれていくようです。

タグ: AWS (3ページ目 (3ページ中))

m1.smallのswap領域にエフェメラルストレージ。

EC2でm1.smallなインスタンスを起動してみた(本当はm3.mediumがいいんだけど、予算が足りない…。m3.smallとか用意してくれないだろうかって無理か)。AmazonLinuxを使ってたら、swapをどうするか心配しなくていいんだろうけど、やはりお金がない状況下なのでCentOS6を選択。

そしたら、swapが存在しない。EBSの上にファイルを作ってswapにしてもいいけど、データの出し入れで課金されるタイプのストレージを使ってたら(ま、たいした金額にはならないような気はするけど)、なかなか切ないことになりそうだけど、インスタンスストアというか、エフェメラルストレージを使ってswap領域を作ることにした。

…とはいえ、インスタンスストアを起動時に割り当てておいて、後は、/etc/rc.d/rc.localに対して、

mkswap /dev/xvdf
swapon /dev/xvdf

を追記しただけなんだけど。そしたら、m1.smallは、エフェメラルストレージとして160GBのHDDのストレージが使えるので、160GBのスワップ領域ができた(汗)なんかでかい。

起動時に/dev/xvdfに対してext4あたりのファイルシステムを作って、そこにファイルを置いて、それをswapに使ってもいいような気がしたのでちょっと試してみた。HDDの160GBの領域にファイルシステムを構築するのに時間がかかるのが…ちょっとなぁ。再起動がかかった後、(ファイルシステム作ってて)立ち上がってくるのに時間かかるのが実に微妙。うーむ。

EBSのVolumeTypeにSSD登場。

EC2でインスタンスを起動しようとしたら、VolumeTypeのところが「Maginetic」「General Purpose(SSD)」「Provisioned IOPS(SSD)」に拡張されていることに気がついた。例の如く、日本語のドキュメントは間に合っていない雰囲気だけど、英語のドキュメントは用意されている。→「Amazon EBS Product Details」を開いて、英語に切り替えると、それぞれのVolumeTypeの詳細が表示された。

端的には、SSD-backedなEBSが使えるようなったらしい。で、これまでのstandardのEBSはMagneticと改称された(ま、SSDじゃないってことはHDDなんだろう)。んで、そのIOPSは、Magneticが平均すると100IOPSくらいで、General Purpose(SSD)が使う容量の3倍のIOPSらしい。つまり、20GB使うと、60IOPS。Magneticより少ないじゃないか…と思いがちだけど、30分の間、3000IOPSまでバーストすることができるらしい。うーむ。30分ってどういうことだろう。3000IOPSが30分続くと制限される(制限されて、使っている容量の3倍のIOPSになるのかな)ってことかな、と勝手に理解しておこうかと思うけど、…なんか違うような気もするな(汗)

んで、料金体系を眺めると、東京リージョンで、「General Purpose(SSD)」が$0.12/GBで、「Maginetic」が$0.080/GB。だいたいSSDの方が1.5倍くらいの値段か。ただ、これに加えて、「Maginetic」の方はI/O requestの課金が加わるが、「General Purpose(SSD)」にはそれがないっぽい(「Provisioned IOPS(SSD)」にはありそうだけど)これまでのEBSのbillを見る限り、割とI/O requestの課金で課金されている雰囲気なので、GB単価で1.5倍の価格差はあれども、意外とと「General Purpose(SSD)」がお得なのかもしれない。

ま、LinodeやDigital OeceanがSSDを積んで、それなりに安いVPSをリリースしているので、業界のリーダーのAWSとしては無視できないってことなんだろうか。

追記:
AWSのブログに、「General Purpose(SSD)」のIOPSに関する解説を見つけた。うーむ、難しい。。。

【AWS発表】新しいSSDベースのElastic Block Storage
http://aws.typepad.com/aws_japan/2014/06/new-ssd-backed-elastic-block-storage.html

AWSで検証してみる

なんとなーくではあるけれど、公衆無線LANでSSLを通らない通信をするのが気持ち悪いので(汗)公衆無線LANからAWSのEC2のインスタンスまでVPNを張って暗号化してみようかと。…まぁ、Amazonから先のネットワークは大丈夫なのかってあたりは気分の問題ってことで。

EC2のmicroインスタンスを、CentOS6のイメージで起動する。L2TP/IPSecを使うので、もろもろのRPMをインストールして、Google先生に聞きながらセットアップしてみた。いろいろはまりながらも、MacOSからL2TP/IPSecのVPNトンネルを作ることはできた…が、インターネットとの通信が通らない(汗)

うーむ。まだ道半ばか…ということで、iptables周辺の設定をチェックしてみよう。

ただ、少し気になったのは、MacOSからはVPNトンネルが張れたけど、Androidからはダメだった。

うーむ。/var/log/messageを眺める限りでは、Androidが使おうとしている暗号方式がダメらしい。…とはいえ、Android側には、そんな設定項目ないから、VPNサーバー側で何とかするしかないのかな…うーむ。

大きなデータをAWSのRDSにロードしたい。

さて、手元に大きなSQLの束がある。MySQLのサーバからmysqldumpしたデータで、サイズは何とか少なくしたけれど50GBはあるだろう。このデータをAWSのRDSのインスタンス(もちろん、MySQL)で使えるようにしたいのだが、いかんせん、データのサイズが大きいので、社内のサーバから動かすのも大変。ウチの社内サーバは、フツーのフレッツでしかインターネットに接続されてないので…と。

思いついた選択肢「その1:直接、MySQLクライアント接続」

ま、RDSのエンドポイントにはインターネットからアクセスできるわけだし*1、社内のサーバからインターネット経由でMySQLのクライアント接続をかけて、SQLを実行しちゃえ、というアイデア。

$ mysql -h [RDSのENDPOINT] -u [User] -p [Database] < XXXX.sql

ま、これでRDSにSQLのデータを入れることはできる。だけど、なんせmysqldumpしたデータは巨大な1つのファイルになっているので、SQLを実行している途中でネットが切れたらやり直しになる可能性が高い。うーむ、なんとなく微妙だ。

思いついた選択肢「その2:(AWSに近い)どこかのサーバにアップロードして、そこから実行」

ま、そもそもインターネットとウチの社内の間がフレッツだから、そこがネットワーク的にボトルネックに違いない。AWSとネットワーク的に近いサーバにSQLの束をアップロードして、そこからAWSに対して、選択肢1のようなことをやればすんなり行きそうな気がしないでもない。ただ、そのサーバとAWSの間の帯域はよくわかんない*2し、そもそも、そのサーバまで巨大なSQLをアップロードするのに時間かかる。gzipで圧縮してアップロードしたいような気もするが、その圧縮にすらうんざりするくらい時間かかりそうだ*3

…とはいうものの…。

他にも、MySQLのデータベース単位でmysqldumpせずにテーブル単位でファイルを作っておけば…とか、いろいろと泡沫のアイデアが浮かんでは消えていった。そして、とても大事なことに気がついた。お財布の都合上、できるだけAWSの無料枠内で納めたい、となると、使えるのは「マイクロDBインスタンス」。まぁ、あんまり性能面ではたいしたことないインスタンスだから、何をどう工夫してもRDSのサーバ側でSQLを実行するところがボトルネックになりそうな気がしてきた。

そんなわけで、何にも考えずに選択肢1で始めたものの…RDSのインスタンスをモニターしてる限りでは、CPU使用率もWrite Throughputもなんだかイマイチな結果になっている。マイクロインスタンスでも余裕がありそうだ。それに、社内でmysqlクライアントを実行しているマシンも暇そうにしている。…ということは、AWSとウチの会社の間のネットワークがボトルネックになっているってことだろうか(汗)やっぱり、MySQLクライアントを実行するマシンとMySQLサーバはネットワーク的に近いところにあった方がいいんだろうなぁと思い始めたが、今から止めてやり直すべきだろうか…どっちにしろぐったりする時間がかかりそうなことだけは間違いなさそうだ。

素人らしく、素人っぽいところでつまずいてるなぁ…いやはや。

追記:

ま、普通にEC2にSQLファイルをどーんとアップロードして、EC2からRDSのインスタンスに対してSQLを実行すればいいんだな、きっと。Amazonのネットワークの中はさすがに遅いって事はないだろうし。…とりあえず、EC2に50GB近くのEBSをAttachすると…ってビビっていたけれど、意外と大して高くないことに気がついてorz

*1:当然、アクセス制限はかけているわけだけど。

*2:たまたま使えるのが、さくらインターネットのVPSなんだけど、石狩だしなぁ…

*3:こういうときに、古いCeleronマシンとかで大きなデータを扱い始めたことを後悔するのだが、時既に遅し

Amazon S3に有効期限機能とか。

どうやら、Amazon S3に有効期限機能が搭載されたらしい。

【AWS発表】 Amazon S3の有効期限機能の発表:
http://aws.typepad.com/aws_japan/2012/01/amazon-s3-object-expiration.html

端的には、S3に格納するオブジェクトに「寿命」が設定できるようになったということだろう。使ったら使っただけお支払いのクラウドサービスにおいては、「寿命」を設定できるのは、(オブジェクトがS3にあるだけで課金対象なわけで)なかなか役に立ちそうな機能であるなぁ、と思う一方で、この「寿命」を設定する機能を使って何ができるだろうと考えると、結構、難しいような気がしないでもない。

まず、なんというか、使いすぎ(ひっくり返せば、放置)を防ぐための保険としての「寿命機能」を使うのはアリだろうな、と思う。とはいえ、memcachedのような容量制限のキツいデータストアにおいては、短命な「寿命」でオブジェクトが消えていくことを前提にアプリケーションは作成できるが、もともと容量制限がないS3において、意味のある形で「寿命」が使えるかとなると…うーむ、という感じはする。

ぱっと思いついたのは、なんかのバックアップをS3に取るだけ取って、古いバックアップの削除については「寿命機能」に任せて、工数削減とか、かな。使えそうだけど、大した工数削減にはなりづらいような気がする。

2012年のITギョーカイはどうなるか。

いつものごとく、ネットを徘徊していたらワシントン・ポストの記者が書いた記事「Five tech industry predictions for 2012」を見つけました。

この記事が挙げている5つ予想を引用すると、以下のような感じでしょうか(雑な訳でアレですが…)

  1. Social media will lose its sizzle.
  2. -ソーシャルメディアの利用が停滞していくだろう。

  3. The bubble will pop for the current crop of tech IPOs.
  4. -tech系のIPOバブルがはじけるだろう。

  5. An explosion of the tablet market driven by sub-$100 tablets.
  6. -$100以下のタブレット製品によって、タブレット市場が旧成長するだろう。

  7. Voice recognition goes mainstream.
  8. -音声認識が主流になっていくだろう。

  9. “Cloudburst” shakes the tech industry.
  10. -“Cloudburst”がITギョーカイを震撼させるだろう

えーと、”Cloudburst”ってのは、クラウドを使ったサービスの利用が加速することって感じの意味で使われているっぽいと。まー、ざっと見た感じではあんまりアグレッシブな予想ではなく、どっちかというとそんなに大外ししない代わりに、斬新さに欠けるような予想のような気がします。

果たして、日本ではどうなるんだろうなぁと考えてみることにしましょうか。

ソーシャルメディアの利用が停滞するというのはそんなに違和感はないんですが、より細かく見てみると、多種多様なソーシャルメディアがローンチされる割には使われないといった見え方になりそうな気がします。確かに、FacebookやTwitterなどの先行者がつかんだユーザーたちのソーシャルメディア疲れは懸念されるものの、人々がソーシャルメディアに費やす時間が大きく減るかというとそうではないような気がします。スマートフォンの普及によって、ソーシャルメディアへの距離感が近くなった(コストが下がった)というのが1つ。それとは逆に、スマートフォンを使って何かしたいという欲求が発生しているなかで、ゲームやソーシャルメディアなど、スマートフォンでできることのバリエーションは実はそんなに大きくないことから、結果的にソーシャルメディアに接触しているといった使い方もあるんじゃないかということがもう1つ。また、(人によるかもしれませんが)TwitterやFacebookがこれまでのメディアでは流通しづらかったような情報(友達のリアルタイムな近況など)を流通させていることから、明確なメリットを感じている人が少なくないのではないか、ということもあるのではないでしょうか。

Tech系IPOのバブルというのは、LinkedInとか、ZyngaのIPOのことを指しているわけですが、特に、いずれもIPO直後の価格が思惑とは裏腹に下降を続けていることを指しているようです。ま、なんとなくGrouponからの流れがあったような気もしますし、FacebookがIPOするとかしないとかって話がありますが、FacebookでもLinkedInやZyngaと同じことが起こるのか、ということも少し疑問です。個別銘柄の事例から傾向を推し量るのは少し難しいのではないかという印象です。

もとい。日本でもIPOの流れは少しありそう(現にKLabのIPOとか)ですが、例えば、ウノウがZyngaに買収されたような、大きく成長したTech系の事業会社によるStartupの買収が増えてきそうな気がします。例えば、SalesForceも国内の事業会社への投資を増やしていそうですし、同じような流れが他の企業(例えば、楽天とか)起きないとも限らない。そういう意味では、IPOバブルになる前に、さまざまなExitでStartUpが買収されていくのではないかという気がします。むしろ、有望なStartupを事業会社、VCなどで奪い合うような、そんな状況が起こる、とか。

次にタブレットマーケットですが、DoCoMoショップなどの端末の売れ行きを見ていると、まだスマートフォンが中心で、Androidタブレットなどは叩き売られているのが現状のようです。逆に言えば、Androidタブレット端末はキャリアとバンドルされた形の販売形式がメインで、WiFiのiPadのような販売形式が見られないのが現状、と。確かに、Asusなどのタブレットの一部は、量販店に並んでいるものの、やはり売れている印象はありません。

ネタ元の記事の$100以下のタブレットというのは、おそらくは中国や台湾のメーカーがAndroidを搭載した安いタブレットを投入してくることを指している(インド製の$35タブレットは現実味を帯びているようですが)のでしょう。むしろ、$100あたりのタブレットは、これまでも投入されてはいたのですが、静電パネルではなく、感圧式のパネルだったり、バッテリーの持ちがひどかったり…と、実際の利用にあたってはかなり厳しい品質で、まともに使えないものだったのが、少しは洗練されてくるということでしょう。確かに、MITメディアラボの創設者のニコラス・ネグロポンテ氏が教育用の$100以下のPC(OLPC)をなんとかつくろうとされていたことを思い出せば、(1)そこそこのスペックで(2)大量に生産することでコストを下げて(3)利用にあたって安価な、もしくは無料なソフトウェアを搭載した端末は成立しうるのではないかという気がします。教育用の他に、家庭での利用シーンを作れるか、そのシーンに応じたソフトウェアを無料に近い価格で用意できるかが$100以下タブレットのキモなのかもしれません。

そして、音声認識。日本語では厳しいのではないかというか、既にGoogleが音声検索用のアプリを無料で提供していますが、まともに使っている人たちを見かけないことから、2012年も日本では音声検索については厳しいのではないかという印象を持っています。スマートフォンにおいても日本語の入力はかなりの問題を抱えているのは確かですが、だからといって音声にぱたっと倒れるほど、問題はシンプルではないように思います。

最後に、クラウドの利用ですが、正直なところ、ITギョーカイの悪習といってもいいのですが、「クラウド」なるものをしっかり定義することなく、既存のものから新しいものまで、ごった煮にしたあげく、なんでも「クラウド」とラベルを貼ってしまうでしょう。例えば、これまでASPサービスって売っていたものを、「SaaS」と言い換えたところで、特段大きな違和感があるかというとそんなこともない。そうなってくると、否が応でも「クラウド」の利用は進むことになるでしょう。「SaaS」くらいになるともうクラウドで動いているかどうかはあんまり関係ない世界なんだろうと思いますが、いわゆる「IaaS」のあたりのクラウドサービスは、これまでの経験の差がモロに反映されてきそうな気がします。新興「IaaS」がいろんなトラブルを経験する一方で、AWSのような老舗サービスは(既に通った道なので)似たようなトラブルには見舞われない、といったような形で差別化が進むような気がします。新興「IaaS」などは価格で差別化するしかなく、規模が小さい「IaaS」ベンダーなどは価格によっては耐えきれなくなったり刷るのかもしれません。また、同時に、新興「IaaS」ベンダーなどはAWSのような老舗サービスをリファレンスモデルにして「似たようなサービス」を作ることによって、スイッチングコストを下げるような戦略も成立しそうな気がします。

…雑に書きなぐったエントリーですが、一応、以上です(汗)

AWSのS3を使ってみるテスト

特に意味はないけれど、AWSのS3ってどんなんだろうということで、なぜかデジカメに残っていた画像をS3にアップロードしてみて、imgタグで表示してみるというベタなことをやってみるテスト。

【むかし、このへんにAWSのS3にアップロードされた写真が貼ってありました】

呼び出されるたびに課金されるのは切ないような気もするけど、ファイルの冗長性とか諸々を気にしなくていいのはもしかすると楽なことなのかも知れない。

DNSとか、Route53でいいんじゃないかとか。

さて、DNSサーバをどうしたもんだか、ぼんやりと考えている。Webでサービスを提供するための前提条件みたいなものだから、非常に重要…ではあるけれど、冗長構成が前提なDNSサーバーがどうにかなって困ると言うことはあまりないせいか、その重要性が理解されづらい。

また、DNSサーバに求められる要件も特段ややこしいことはなく、普通に落ちない鯖であればokで下手なハイエンドマシンなんかもったいない…そんな感じがDNSの存在を埋没させてる気がする。

要するに、いちいちサーバを用意したりするような手間はかけたくないが、ちゃんと動いてて欲しいのがDNSサーバーと言うことになる。

そう考えてみると、極めて簡素にDNSだけ預かりますってサービスに預けてしまうのが手っ取り早いが、フツーのレンタルサーバサービスではDNSだけってサービスは意外と提供されていない。そこで、クラウドである。

AmazonのAWSで提供されている「Route53」っていう名前のDNSサービスが、まさにそのサービスだった。しかも、しばらく前まではAPIしか提供されていなかったのだが、改めてWebの画面が提供されたことで簡単にゾーンファイルを編集できるようになった。

しかも、「Route53」は、世界各地のAWSの拠点において、anycastで提供されているわけだら、ネットワーク的な遅延なども少ないし、冗長性も確保されているだろう。しかも、1ドメインが$0.5くらいで提供されているというのがまた魅力的だ。いくつかのドメインを持っているとしても、「Route53」と単純に価格比較したら、わざわざDNSサーバを購入する妥当性は生まれてこないだろう、という気がする

Newer posts »