では早速紹介していきましょう。 できる！Nyahネットワークトラブルシューティング @buty4649 http://buty4649.jugem.jp ※Nyah: 弊社プライベートクラウドのコードネーム OpenStackを用いたプライベートクラウドの運用にはまだまだ難題があり、ネットワーク周りのトラブルシュート事例とアーキテクチャを説明してもらいました。 以前利用していたバージョンのHavanaではL2スイッチを利用したbridge接続を利用していたため複雑な構成ではありませんでした。現在はMitakaを利用しており、Neutronを用いたDVRの運用に切り替え中です。まだまだ国内プロダクション環境での事例コンテンツが多くはないため試行錯誤した苦労や歴史を、普段OpenStackプラットフォームを利用しているエンジニアに理解してもらえたと思います。 ネットワークの基礎知識から体系立て
(Monitoring Casual Talk in Kyotoで発表してきたので、ブログエントリにまとめ直しました) 2013年はインフラ周りの技術的な進化が大きく、いくつかのエポックメイキングな概念と実装が産まれました。個人的には特に以下の2つが大きいと思っています。 AWSの本格普及期 DockerとImmutable Infrastructure これらを踏まえて、2014年のウェブシステムの進化の方向性を考えてみます。また、それによるモニタリングへの影響もあわせて考えます。だいぶ長くなってしまったので、急ぐ人は最後に結論をまとめましたので、そちらからどうぞ! 2013年という時代背景 AWSが本格普及期を迎えているのは、言わずもがなのことで、Re:Inventでの246件という膨大のセッション数などにその勢いが表われています。 また、DockerはLXC (LinuX Conta
ここ最近のインフラ系技術の流れがおもしろいなー、と思ったので、Puppet が出た辺りぐらいから、振り返って整理してみる。殴り書きなので、後から修正したり書き加えたりするかも。特に後半の方は、あまり考えが整理できてない。 最近のウェブ界隈での「インフラ」という用語の使われ方には、色々異論もあるようだけど、ここではごく最近使われるようになってきた、OS からミドルウェアといったソフトウェアレイヤーを指す言葉としてのインフラについて触れる。（英語圏でも同様の意味で使われているようなので、ある程度市民権を得たと言っても良さそうだし。） プロビジョニングレイヤー まず、前提知識としてプロビジョニングレイヤーと自分が勝手に呼んでるものについて整理。 Chef や Puppet は「プロビジョニングフレームワーク」とも呼ばれているが、以下の議論をより厳密にするために、Lee Thompson 氏による
わんばんこ、ザビオです。 AWS Advent Calendar 2013の18日目の記事です。 多くは語りませんが、いつまでも待っています。 題名の通りですが、容量が大きいファイルはS3のmultipart uploadを利用すると通常送信より早く送り終わるみたいなのですが、multipart uploadを利用した際に、どれくらい早くなるのか、測ってみようと思ったので、測ってみました。 multipart uploadなし 容量 実行完了時間 1MB 0.754267 sec 5MB 1.990114 sec 10MB 3.154825 sec 100MB 15.70757 sec 1GB 211.044775 sec multipart uploadあり 容量 実行完了時間 1MB 0.783278 sec 5MB 1.652858 sec 10MB 3.467234 sec 100
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
