ワールドビジネスサテライト砲を乗り越える時にやったこと - 素数好きの最高技術責任者のブログ
先日2013年11月25日（月）にテレビ東京さんのWBS（ワールドビジネスサテライト）に弊社サービスのrecme[レクミー]を取り上げていただきました。 というわけで、急激なアクセス増加に耐えるために打った対策を、時系列順にまとめておきます。 11月22日（金） 〜 放送3日前 〜 EC2インスタンスを沢山並べるために、デフォルトの20台制限を100台にしてもらうようにここのフォームから申請する。 ELBの暖気運転を申し込むため、AWSサポートのビジネスプランに申し込む。 ちなみにAWSサポートは1ヶ月単位の申し込みではなく日割りで清算してくれるようなので、必要な瞬間だけ申し込むことが可能とのこと。 EC2インスタンスはc1.medium（c3.largeにした方が良かったと思ってますが）を2つのゾーンに10台ずつ並べる。 目標は秒間3,000アクセスを優雅に捌くこと。 11月23日（土）
AWS News Blog
Amazon SageMaker Geospatial Capabilities Now Generally Available with Security Updates and More Use Case Samples At AWS re:Invent 2022, we previewed Amazon SageMaker geospatial capabilities, allowing data scientists and machine learning (ML) engineers to build, train, and deploy ML models using geospatial data. Geospatial ML with Amazon SageMaker supports access to readily available geospatial dat
【AWS】クラウド時代のバックアップ管理術 ～tagを活用したsnapshotの世代管理～
こんにちはfujyaです。 今日はAWSの超便利な機能、snapshotを良い感じに使うTipsを紹介したいと思います。 AWSのsnapshotは超便利なので色々なサーバのバックアップ用途としてがんがん取得したくなりますが、数十台・数百台にサーバが増加すると管理が煩雑になってしまいます。これをスッキリさせるために、マネジメントコンソール上で「世代数の管理」と「snapshot対象かどうか」を分かるようにしてみました。 手順としては4Stepで環境が構築可能です。 1：snapshotを取得したいインスタンスのtagにbackup:ON / generation:N（世代数）を設定する 2：apitoolsがインストールされてるサーバにX.509証明書を設置しておく 3：2のサーバにsnapshot取得スクリプトを配置 4：CronもしくはJenkinsで定期的に3のスクリプトを実行する
『AWSのオプション設定(Auto Scaling)』
最近の必準品は "MINTIA ~クールマスカットミント~ " です。 いま「必準品」って変換がどうしてもできなくて、コピペしました。 読み方がわかりません。 ひつじゅんひん しつじゅんひん でない・・・ こないだTVでやってた日本語検定の一番簡単な級の問題もわかんなかったしな。。 「～は」と「～が」とかどっちでもえーわ！！ 「王様」とか「雰囲気」とか「授業」とか、ほんと変換できない。 "帰国子女だから"ですべて片付けようとおもいます。 【Auto Scaling】 ELB設定されているインスタンスが落ちた時に、 自動的に新しくELB配下にインスタンスを生成し、サーバーを起動させるシステム 逆に不必要な時に落とすこともできる すばらし どうやらこの設定、いまのところGUIではできないらしいのでコマンドでAPIをげっちむ 【APIダウンロード】 # yum install auto-scal
AmazonEC2 m1.smallのCPU配分 | Linux練習帳
AmazonEC2のサーバのCPUは、ECUという単位の処理能力で表現されます。標準的なインスタンスである、m1.small, m1.large, m1.xlargeでは、それぞれ、1ECU*1コア, 2ECU*2コア, 2ECU*4コアという風に表されています。ここで気になるのは、m1.smallだけ、1コア当たりの処理能力が低いという事実です。m1.small以外のインスタンスではCPUコア当たりの処理能力は2ECUなのですが、m1.smallだけは1ECUです。m1.smallだけ異なるCPUが割り当てられているとは考えづらいので、おそらく時分割で共有しているのでしょう。Amazonのサイトで具体的な記述を見つけることが出来なかったので、実際に検証してみました。 スモール インスタンス – デフォルト* 1.7 GB メモリ 1 ECU（1 ECU × 1仮想コア） 160 GB イ
主にEC2内部用のDNSサーバ - ddns - so what
※後継のMurakumoを開発中です。 https://bitbucket.org/winebarrel/murakumo/ http://d.hatena.ne.jp/winebarrel/20111202/p1 某勉強会でddnsのことを話したのですが、ほっとくと忘れ去られそうなので記事にまとめたいと思います。 https://bitbucket.org/winebarrel/ddns https://rubygems.org/gems/ddns これは何？ 主にEC2での利用を想定した内部向けDNSサーバです。 ddnsはDynamic DNS…ではなくDistributed DNSの略です。直訳すると分散DNS。 ひどすぎる名前ですね。最悪です。gem pushしてから後悔しました。 まあネーミングセンスがないのは昔からです。 一般的なDNSサーバと違って、ホスト名の情報を分散管理
Amazon EC2(Vyatta)からAmazon VPCに接続してみた - log4moto
Amazon EC2(Vyatta)からAmazon VPCに接続してみた 「さくらのVPSにVyattaを入れて、Amazon VPCにVPN接続」を見て、EC2でもつないでみようと思い立った。 準備 AMIはVyattaのAMIを使いました。インスタンスタイプはt1.micro。 ネットワーク構成はこんな感じ。 基本的なconfigはid:iamsandmanさんのページを参考にして作成したが、EC2で動かすにあたって一部変更が必要だった。 NAT環境なので、eth0はプライベートアドレス(dhcp)となる。IPsecやlocal側のサブネット用のアドレスはloopbackにとりあえず振ってみた。 interfaces { loopback lo { address 169.254.255.2/32 address 169.254.255.6/32 address 172.22.0.1
qpstudy１周年 ＆ hbstudy#22でLTしてきたよ～OpenVZで始めるDR～
先々週の土曜日（２０１１年４月９日）にqpstudyという馬鹿騒ぎ飲み会勉強会と先週の土曜日（２０１１年４月１８日）にhbstudyに参加してきました。
【AWS】Tokyo Regionからコンニチハ！～OpenVZがTokyoにやってきた～
SingaporeからTokyoへ引っ越しました記念ブログ。 どうも、fujya.shです。3月3日夜に突然のTokyoRegionの発表でTLが一気にTokyoRegionNightになってしまいましたね。私も興奮し勢い余ってSingaporeで稼動していたEC2のサーバをTokyoへの引越し作業に没頭してました。とりあえずSingaporeのEC2で稼働中のOpenVZサーバをTokyoへの引越しができましたので、移行手順とやった事などを投稿したいと思います。 AWSではRegion間またがってのEBSタイプのAMIのコピーがサポートされていません。instance-storeタイプのAMIはS3に保存されているため、どこのRegionからも参照できます。SingaporeにあるEBSタイプのAMIをTokyoに引っ越すためには一度instance-storeタイプに変換させる必要があ
Amazon EC2性能検証！気になるパフォーマンスをインスタンスタイプやリージョン毎に計測・比較してみた - 元RX-7乗りの適当な日々
大手クラウドサービスであるAmazon EC2では、9種類ものインスタンスタイプ(サーバの種類)から、利用したいスペックのサーバを選択できます。また、EC2のサーバは、4ヶ所ものリージョン(アメリカ東海岸、同西海岸、ヨーロッパ西部、シンガポール)から稼動させる場所を選択することができます。 ここで、気になるのが、Amazon Web Servicesの説明ページで、各インスタンスタイプの公表スペック差異として、EC2独自のCPU単位である"ECU"の数値や、IO性能のModerate(中)やHigh(高)で、どのくらいパフォーマンスが違うのかが見え辛いといった点。 また、一部の場所ではパフォーマンスが出ていない等の話が以前に出ていましたが、4ヶ所のロケーション(Region)によって、各場所でのインスタンス性能が全く同じなのか等も気になるところ。 ここを解明すべく、各種ベンチマークを実行し
AmazonEC2を何倍もお得に使う方法
今回はシャノンでAmazonEC2を使う機会がありましたので、そのお得な使い方を紹介したいと思います。 「サーバの仮想化」今では当たり前になってきました。1台のサーバで複数台動かす事で、一人一開発環境を実現したり、アプリケーションをバージョン毎に保管できたりと至れり尽くせりです。 シャノンでも100台以上のサーバを仮想化して使っています。仮想化することで、開発環境を5分で用意できるようになりましたし、サービスを提供している、いわゆる本番環境のサーバ増設も1時間以内でできるようになりました。 アプリケーションサーバ、キャッシュサーバ、データベースサーバ、ロードバランササーバ、メールサーバ、開発環境、テスト環境用サーバ等々と数十種類のサーバイメージを管理しています。 本当に便利な時代になりました。 ■ シャノンではOpenVZを使っています シャノンではOpenVZという仮想化ソフトを使ってい
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
