#jawsdays の #最強のAWS で「ぜんぶ AWS でやらないワケ」という話をしてきた · takus's blog
@hirose31 さん経由で @con_mame さんからお話をいただき、 JAWSDAYS 2014 の「これで最強AWSに」というセッションで話をしてきました。 内容としては、オンプレも AWS も運用してる立場から両者を比較してみてどうなのといった感じのお話です。 2014/03/15 JAWS DAYS 2014 - 『これで最強のAWSに』セッション #jawsdays #最強のAWS にツイートまとめがあるので、資料と一緒にご覧いただければと思います。 こんな話も出ていましたが、 AWS は必ずしも銀の弾丸ってわけではなく、どこの会社も悩ましい部分を抱えながら運用しているわけで、 @sgwr_dts さんの Roadworker のようにユーザ側でイケてる仕組みにするようなアプローチもありますが、このような機会を利用して AWS の中の人に直接フィードバックできたという意味で
運用視点でChef ServerかChef Solo + Knife Soloのどちらが良いか考えてみた - プログラマでありたい
ChefとFabric、どちらが良いか悩んでいるうちに、Chefが一気にブレイクしてしまった今日この頃です。と言うことで、Chefを中心に今後のサーバ構築・運用について考え中です。そこでまず出てくる問題が、Chef Server+ClientとChef Solo + Knife Solo、どちらの構成が運用しやすいかという点です。 状況を整理する為に、まずは簡単にChef Server, Chef Solo, Knife Soloの関係や役割をまとめて見ます。 Chef Server サーバーの状態を管理し、それに関する情報を保持しておくのがChef Serverです。Client側は個々のサーバにインストールされて、Chef Serverに司令を問い合わせて実行します。Chef ServerはDBやキューなどを持ち、少し複雑な構造です。同じカテゴリーの製品として、PuppetやFabri
Labeled Tab Separated Values (LTSV) ノススメ - stanaka's blog
追記(2/8 11:30) id:naoyaによる一連のまとめが【今北産業】3分で分かるLTSV業界のまとめ【LTSV】 - naoyaのはてなダイアリーにあります。 また、仕様などをまとめるために http://ltsv.org/ を立ち上げました。 追記ここまで Labeled Tab Separated Values (LTSV) というのは、はてなで使っているログフォーマットのことで、広く使われているTSV(Tab Separated Value)フォーマットにラベルを付けて扱い易くしたものです。はてなでは、もう3年以上、このフォーマットでログを残していて、one-linerからfluentd、Apache Hiveまで幅広く便利に使えています。 ログフォーマットに期待されることは、 フォーマットが統一されている → 共通のツールで集計し易い 新しいフィールドの追加が容易 → サー
【CyberAgent】技術情報／TechReport - テックレポート／MongoDBの運用について | 株式会社サイバーエージェント
■はじめに 弊社でも、ピグライフをはじめとしてモバイルゲームなどのサービスでMongoDBを使い始めています。 運用に関してはMySQL等にはまだノウハウ的にはかなわないものの、NoSQLのジャンルの中では有用なプロダクトであるといえるかと思います。 ですが、運用に関しての共有ができておらず、有効な使い方ができていないパターンも多いです、そのため運用に関してノウハウを共有するための資料を作成しました。 ■概要／特徴 MongoDBには以下のような特徴がある ● BSONによる、JSONによるスキーマレスなデータ運用 これにより、柔軟なデータ構造をわかりやすく表現できる。 加えてスキーマレスなため、データの構成を柔軟に帰ることが出来る ● レプリカセットによる冗長化対応 MySQLでも、マスタを冗長化するためには、MySQLCluster、MHAなどのプロダクトがあ
実践GitHub Pages運用のユースケースとワークフローの詳細 | ゆっくりと…
前回、GitHub Pages 活用の概要を書きましたが、実際に運用していくと、master と gh-pages をどう使い分けるか、また両者の同期をどう行うかなど、いくつかの課題が浮かび上がってくると思います。 そこで今回は、実際に GitHub Pages 上で運用されている Dive Into HTML5 をよく知る立場から書かれた記事 「GitHub Pages Workflow and deleting git’s `master` branch – Oli.jp」 の翻訳を中心に、関連するいくつかの記事から、ユースケースと運用のシナリオ、及びそれに応じたワークフローをまとめてみました。 以下は、その参考記事です。 Git post-commit hook to keep master and gh-pages branch in sync by Paul Irish 2011
MySQLの冗長化 2013-01-24
2. © MATSUZAKI Yoshihiko 2013.1.24 自己紹介 • 松崎 慶彦 (MATSUZAKI Yoshihiko) • 株式会社ハートビーツ 運用エンジニア ▫ MSP(サーバ運用・監視)の会社 ▫ 24時間有人監視を提供している ▫ ベンダ非依存なサーバ運用(どこでもやる) • 普段やっている業務 ▫ サービス特性に合ったインフラの設計・構築 ▫ サービス特性に合った運用の設計 ▫ すでに動いているサービスの移設
私がMuninに恋する理由 - インフラエンジニアでも監視がしたい！ -
7. ＼ / 私は誰？ ＼ 丶 i. | / ./ ／ ＼ ヽ i. .| / / ／ ＼ ヽ i | / / ／ ＼ -‐ Zembutsu Masahito ー _＿ わ た し で す -- • 前佛 雅人 @zembutsu 二 ／￣＼ ＝ 二 ￣. | ＾o＾ | ￣ -‐ ＼＿／ ‐- – Solutions Engineer ( 萌えるSE ) ／ • インフラエンジニア的な仕事メイン / ヽ ＼ • 株式会社リンク at+link サービス開発部 ( http://www.at-link.ad.jp/ ) ／ • “技術者に安心と休息を” 提供するサービス追求(運用/監視/自動化) 丶 ＼ ／ / / | i, 丶 ＼ ／ / / | i, 丶 ＼ – オープンソース系・クラウド系コミュニティ活動 • http://pocketstudio.jp/log3/ – 主な職歴
現代のソフトウェア／サービス開発で構成管理が重要になった5つの理由
現代のソフトウェア／サービス開発で構成管理が重要になった5つの理由：DevOps時代の開発者のための構成管理入門（1）（1/2 ページ） 「DevOps」という言葉にもあるように、ソフトウェア構成管理は、インフラ運用に取り入れられるなど、変わりつつある時代だ。本連載では、そのトレンドにフォーカスして、現在のソフトウェア開発に有効な構成管理のノウハウをお伝えする もはや以前の「構成管理」ではない ソフトウェア構成管理はソフトウェア開発の現場で一般的になってきましたが、それを取り巻く状況は2000年代中盤と比較して、ソフトウェアビジネスのトレンドや使用するツールなど、ずいぶんと変わってきています。 読者の方の中にも「Gitそろそろ覚えないといけないのかな？」「Jenkinsって何がうれしいのだろう？」「開発のサイクルが以前より短くなって大変だな」などと感じていらっしゃる方もいらっしゃるのではな
危なくないgitこと、うちのチームのgit戦略草案(ver. 2)
履歴 恥を忍んで記事を公開させていただいたおかげで、いろいろフィードバックいただきました。フィードバックを取り込んで更新を行なっています。 2012/11/16: cherry-pickしやすいように、というくだりのところは論理通ってないので削除しました。 1 pull req. 1 commitの原則をやめました。言いたいことであった「試行錯誤の過程を入れないで」を丸パクリしました！ > id:kazuho その他表記修正、クリアコードさんの記事に説明丸投げなど。 まえがき gitでトラブった！という話を何度か聞いたことがあります。なんでトラブッてるんだろう…と話を聞いたところ、同一のリモートブランチに対して複数人・複数環境から操作が行われているようです。極端な例を挙げると、masterブランチしか存在しておらず、コミットログをキレイにするためと称してgit pull –rebaseを常
「MongoDBのはじめての運用テキスト」を書いてみた - 256bitの殺人メニュー
MongoDB使いましょって時に、やれ、レプリカセットだの、シャーディングだの、いちいち手順とか教えていくのがめんどくさくなったので、これを見たらコマンド的な手順はひと通りいけますよ。だから後は自分で調べてね、っていう資料をつくってみたのだ。 というわけで、「MongoDBのはじめての運用テキスト」SlideShareにあげました。 MongoDBのはじめての運用テキスト from Akihiro Kuwano 内容 PDFには、以下の様な内容を盛り込んでいます。 インストール レプリカセット構築 シャーディング設定 基本的なオペレーション Stat系ツールの見方。 ただし、徐々に古い情報にはなってくると思うので、詳しい情報や、最新の情報を見たい方には公式のWikiなり、ソースなり見ていただくのを推奨いたしますｗ 意図 以前MongoDBの薄い本などもあって、あれはすごくわかりやすい入門テ
GitHub Flow (Japanese translation) Latest version is here: https://gist.github.com/Gab-km/3705015
GitHub Flow Scott Chacon on the Interwebs 31 Aug 2011 git-flowの問題点 (Issues with git-flow) 私は人々にGitを教えるためにあちこちを飛び回っているが、最近のほぼすべてのクラスやワークショップでgit-flowについてどう思うかを尋ねられた。私はいつも、git-flowは素晴らしいと思うと答えている。何百万ものワークフローを持ったシステム（Git）を提供し、ドキュメントもあるし、よくテストされている。フレキシブルなワークフローは、実に容易なやり方で多くの開発者の役に立つ。標準的なものになりつつあり、開発者はプロジェクトや企業の間を移動しつつこの標準的なワークフローに馴染むことができる。 しかしながら、それ故の問題も抱えている。新しいフィーチャーブランチをmasterではなくdevelopから開始するとか、
git flow でのチーム開発ワークショップ資料 - Yamashiro0217の日記
この記事は会社内の別チームの方に、 僕の今のチームで git をどう運用してるかを ワークショップ形式で説明するための資料である。 事前準備 git と git-flow を入れておくこと 参考資料(Macでgitとgit-flowインストール) - xcode cli toolインストール -- https://daw.apple.com/cgi-bin/WebObjects/DSAuthWeb.woa/wa/login?appIdKey=d4f7d769c2abecc664d0dadfed6a67f943442b5e9c87524d4587a95773750cea&path=%2F%2Fdownloads%2Findex.action - homebrew のインストール -- https://github.com/mxcl/homebrew/wiki/installation - b
Amazon EC2上のサーバー開発と運用方法をARMORED CORE Vのインフラで学ぶ
CEDEC2012でフロム・ソフトウェアの恵良和隆さんが「ARMORED CORE Vのオンラインサービスにおけるクラウドサーバー活用事例」というタイトルで、Amazon EC2上でゲームサーバーを運用する場合に解決しなければならない問題点と具体的な解決方法について講演しました。 恵良和隆： 「ARMORED CORE Vのオンラインサービスにおけるクラウドサーバー活用事例」というタイトルで行いますので、よろしくお願いします。 まず簡単に自己紹介をさせて頂きます。2002年にフロム・ソフトウェアに入社しまして、基本的にはライブラリの開発だったりとか、開発環境の構築とかバックエンドのサポートの仕事をしていたんですが、2007年のmeet-meぐらいから、オンライサービスの開発に携わって、そこから大体5年ぐらいオンラインゲームに関することをやっていました。今回お話する「ARMORED CORE
ぼくが実際に運用していたGitブランチモデルについて
オペレーションとかインフラ系のエンジニアリングからは少々離れそうなので、個人的な備忘録がてら、Gitのブランチモデルについて。淡々と書くよ。 見えないチカラ: A successful Git branching model を翻訳しました 基本的に、このA successful Git branching model（上記は翻訳記事）を参考にしています。ですが、完全ではありません。運用しながら都合よく省略していますし、悪く言えば曲解もしています。あくまで、わたしが都合良く解釈して取り回した結果と考えてください。 さて、このようなドッシリとしたブランチモデルが、あらゆる規模のプロジェクトに対して有効であるかといえば、もちろんそうではありません。コツコツ個人で開発しているライブラリなどは、ブランチを使わなくても良いケースがあるでしょうし、作ってもバージョン番号ブランチぐらいのケースだってザラ
h300 にかかった CDN 利用料と、それを半分に抑えてくれた JPEGmini - おいちゃんと呼ばれています
少し前に書いたエントリーでは、h300 にどっと押し寄せたアクセスを捌くために、画像ファイルを別サーバに移したり、最終的には AWS の CDN である「Amazon CloudFront」を導入したことなどを、その判断基準も含めてまとめました。 -オシャレエロサイト「h300」をリリースして、10万PV/日を捌くためにやったこと それに対して、1番よく訊かれたのが で、ぶっちゃけ、結局サーバ代（CDN 利用料含む）にどれだけかかったの？ << という質問でした。 ぶっちゃけたところを、書きます。また CDN 利用料を抑えるために JPEGmini という Web サービスが非常に役に立ったので、併せて紹介します。 **h300 にかかった CDN 利用料と、それを半分に抑えてくれた JPEGmini -1. h300 のサーバ代は、ぶっちゃけ 3万円/月 -2. CDN 利用料を半分に抑
1台から500台までのMySQL運用 MySQL Beginners
5. On-Demand WorkforceWorkforce On-Demand On-Demand Workforce On-Demand Workforce On-Demand Workforce Our Service (livedoor) Amazon MechanicalAmazon Mechanical Turk Mechanical Turk Amazon Mechanical Turk Mechanical Turk Turk Amazon Amazon t/ Workers Workers Requester Requester On-Demand WorkforceWorkforce On-Demand On-Demand Workforce On-Demand Workforce On-Demand Workforce Amazon MechanicalAmazon
Instagram のスケール正攻法 -- Kosei Kitahara's Blog
Instagram がどこに買収されたとかは他のニュースサイトにお任せして、Django アプリケーションを正攻法でスケールして "成功" してるのがとても興味深いです。現時点で Instagram Engineering で紹介されていることと TechCrunch にも掲載されたスライドから個人的なメモとしてまとめてみました。 Instagram の哲学は シンプルであること オペレーション負荷を最小化すること すべて装備 とのこと。 Instagram は以下の OSS, サービスで構築されているようです。 >>> OS / ホスティング Ubuntu Linux 11.04 を Amazon EC2 にホスティング。以前のバージョンは高トラフィックになると固まる問題があったようです。運用は 3 人。EC2 にホスティングしている理由は、調査結果によるものではなく、"まだ進化途中だか
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://paperboy-all.github.io/docs/nagios/learning.html
AWS費用試算例 · さよならインターネット
1台から500台までのMySQL運用(YAPC::Asia編)
