インフラ系技術の流れ - Gosuke Miyashita
ここ最近のインフラ系技術の流れがおもしろいなー、と思ったので、Puppet が出た辺りぐらいから、振り返って整理してみる。殴り書きなので、後から修正したり書き加えたりするかも。特に後半の方は、あまり考えが整理できてない。 最近のウェブ界隈での「インフラ」という用語の使われ方には、色々異論もあるようだけど、ここではごく最近使われるようになってきた、OS からミドルウェアといったソフトウェアレイヤーを指す言葉としてのインフラについて触れる。（英語圏でも同様の意味で使われているようなので、ある程度市民権を得たと言っても良さそうだし。） プロビジョニングレイヤー まず、前提知識としてプロビジョニングレイヤーと自分が勝手に呼んでるものについて整理。 Chef や Puppet は「プロビジョニングフレームワーク」とも呼ばれているが、以下の議論をより厳密にするために、Lee Thompson 氏による
インフラエンジニアのキャリアとして大手ベンダーから始めるのも悪くない | debiancdn
私は、AWSで提供しているサービスは間違いなくインフラの中核技術であること、今後もAWSはインフラの中核技術を出し続けるであろうことを確信しています。AWSというのを「クラウド事業者」「大規模事業者」などなどに置き換えてもいいでしょう。しかし、それらの今うまくいっているプレイヤーに「乗っかる」戦略もそんなに悪いものではないと思っています。 Open database life: インフラエンジニアのキャリアとクラウドについて ではこれからLinuxなりMySQLなりのスペシャリストになりたいという人(新卒/中途問わず)はどういう会社を目指すのが良いのでしょうか。私は本家ベンダー(RedHatなりOracleなり)や大手サービス事業者(FacebookなりDeNAなり)が良いと思っていますが、一点「クラウド上で主力サービスを展開している事業者」はやめた方が良いと考えています。 Linuxなり
インフラエンジニアのキャリアとクラウドについて
もう注目されるようになって久しいクラウドについて、思うところを書いておきます。 LinuxなりMySQLなりといったインフラ技術のスペシャリストの人が、GoogleなりFacebookなりといったサービス事業者で働くことは珍しくありません。これはそうしたサービス事業者にとって、インフラ技術のスペシャリストがある程度必要だということでもあります。ではこれからLinuxなりMySQLなりのスペシャリストになりたいという人(新卒/中途問わず)はどういう会社を目指すのが良いのでしょうか。私は本家ベンダー(RedHatなりOracleなり)や大手サービス事業者(FacebookなりDeNAなり)が良いと思っていますが、一点「クラウド上で主力サービスを展開している事業者」はやめた方が良いと考えています。 なぜなら、インフラ技術を語る上で欠かせないハードウェアとネットワークが、クラウド上ではブラックボッ
mixiのサーバーOS移行について
日本最強の看板を下ろしたミラーサーバftp.jaist.ac.jpの管理者の一人が、 このサーバにまつわるよしなしごとを語ります。 English versions of some posts on another blog. mixiのサーバーOSの移行の話がブログ(mixiのサーバOS移行のお話、mixiのサーバOS移行のお話 - 前回補足＆インストール編)で公開されました。移行先がFedora 17だったことについて否定的な見解を示す人が多いです。私ならこの選択はしませんが、真っ向から否定するほど合理性を欠く選択だったとは思っていません。 移行する前はmixiはFedora 8で運用していました。 Fedoraプロジェクトによるパッケージの更新が止まったあとは、長年自力でメンテナンスしています。mixiのLinuxシステムは、当初のFedora 8とは大きく異なるものになっているはず
mixiのサーバOS移行のお話 - 前回補足＆インストール編 - mixi engineer blog
こんにちは。新しもの好きが集まる運用部アプリ運用グループの清水です。 前回の記事では、多くの反響をいただきました。ありがとうございます。 Twitterや、はてブのほとんどのコメントを読ませていただきました。 みなさんのOSの宗派が垣間見えた気がします。 さまざまなコメントをいただいていた中で、よくある代表的なコメントについて、改めてこの場を借りてお答えしたいと思います。 2012年12月28日追記: 以下のQAにつきまして、いわゆる"ネタ"として書きましたが、誤解を招き、不適切な表現で不快な思いをされた方々へ深くお詫び申し上げます。 また、QAの一部に関わるところですが、OS標準のパッケージを否定するつもりは全くございません。 Linuxを安心して使うことができるのは、Linuxディストリビューションに携わっているデベロッパーの方々の素晴らしい活動や成果によるもの、というのが揺るぎない事
ドリコムのソフトウェア選択のお話 | 外道父の匠
mixiのサーバOS移行のお話 – mixi Engineers’ Blog とその続編に触発されて、私の寄生先であるドリコムではどのように考え、何を選択してきたのか振り返ってみたいと思います。 こういう情報の公開は、確かにしないに越したことがない類のものかもしれませんが、年末ですし、当たり障りのない範囲で思い出エントリで締めくくろうかなと思い立った次第であります。 OSの選択を振り返る 2001年あたりから覚えている範囲でザッと振り返ると、 RedHat 7-9 FedoraCore 1-3 Debian 3-6 CentOS 4-6 という感じで、現在はDebian(5/6)とCentOS(5/6)を主流で利用しています。あとはたまにBtoB案件とかでWindowsServerやRHELもちょこちょこありましたが、今はないですね。 こういう選択をしていった理由は、 まずRedHat～F
キャパシティプランニング 発表資料 | 外道父の匠
久々に社内向けに勉強会を行いました。 既に稼働しているサービスの、サーバの台数調整の考え方についてです。半分くらいは口頭で話したので資料だけでは物足りないかと思います。が、せっかくなので公開しておきます。 内容はインフラ管理についてですが、対象者はどちらかというとアプリケーションエンジニアとして作成・発表しました。資料と、ブログ用に補足を書いていきます。 作りやすくて頼りになるので、 もう、赤さんはテンプレでいいかな、とも思い始めました。 補足 勉強会をするに至った理由 いわゆるインフラエンジニアが、サーバの負荷状態を観測したり、台数を判断できるのはアタリマエですが、サービスを作成しているアプリケーションエンジニアにとってはアタリマエではなかったりします。 理想としては、WEBエンジニアたるもの、自宅サーバやレンタルサーバを１つは持っていて 総合的な知識を得ようとする環境・努力をして欲しい
月額5万円から始めた写真共有サービス「Snapeee」のAWS活用法 - builder by ZDNet Japan
アジア主要都市11カ国でApp Storeカテゴリ1位を獲得するなど、女性に人気の写真共有サービス「Snapeee」。スマートフォンで撮影した写真をプリクラのようにデコレーションして共有できるのが特徴で、今年8月に累計200万ダウンロードを突破。ユーザーの8割が女性で大半が20代だ。 このSnapeeeを運営するマインドバレットでCTOを務める神尾隆昌氏がAmazon Web Services（AWS）を利用するスタートアップ向けワークショップ「Go Global with AWS！ - Hands on workshop -」（AWSとサンブリッジの共催）に登壇。同社におけるAWS活用のノウハウと課題を明かした。 「写真デコ」で世界の女性ユーザーの心をつかむ 写真を「デコ」して共有する女性向けサービスというコンセプトを構想し始めたのは2010年後半。同年10月にInstagramが発表さ
Pinterest のスケール
V 先生から教えて頂いたので、Instagram 同様 Django/AWS 構成の Pinterest のスケールをメモ。Pinterest はいつものアカウント名が初めて 先取 されたサービスなので、今後使わないと思います。 本題に入る前に、Python には The Zen of Python (日本語) という思想があります。私はこの思想を Python でのプログラミングだけでなく、インフラの構築の際も意識するように心がけています。"Simple is better than complex" です。Instagram や Pinterest のスケールを見て、この思想がもっと好きになりました。 Instagram はよりシンプルなインフラに更改していくことで、ただスケールするだけでなく、運用や変更のコストも最小限になるように最適化していると思います。結果的に Android ア
Netflix のスケール
現在日本でサービスを提供していないため目にすることは少ないですが、AWS のベストプラクティスと呼び名が高い Netflix のスケールをメモ。ベストプラクティスと言われるだけあって、記事も解説も豊富です。まー規模が桁違い過ぎるので読み飛ばしていたってのが正直なところですが、V 先生ドリブンで資料を読み直しました。AWS の How-to 記事は日本語でも山ほどあったので、自社データセンターから AWS へ移行した過程を中心に書きたいと思います。Netflix のテクノロジーについては以下を参考にしました。 The Netflix Tech Blog @slideshare @github >>> サービスの規模 Netflix は主に北米で VOD と DVD 郵送レンタルサービスを提供している会社です。ほとんど VOD で、今後 DVD 郵送レンタルは縮小するらしい。AWS の資料も
「GREEを支える大規模インフラテクノロジー」-GREE Platform Summer Conference 2012
取締役 執行役員CTO 開発本部長 藤本 真樹氏 2005年6月にGREEに入ってから7年が経ちました。 GREEでは開発全般を見ていて、最近はインフラよりもクライアントの方を見ますが、元々はサーバーサイドよりの人間なので、今回こういう話ができて嬉しいです。 今回のお題でサーバーサイドに関して話してみては？ と言われて、すごく困ってしまった。 何故かというと、大規模サービスを普通にやるテクノロジーのコモディティ化が進んだからです。 １０倍のユーザーが来た時にどうすればいいのかというのは、インターネット上にいっぱい情報が既にあり、それを支えるオープンソースのプロダクトや、クラウドサービスなど解決策がいくつもある。 Agenda 1.Infrastructure for over 100,000,000users 2.Infrastructure for global ser
資料公開 Chefの下準備 (#DevLove Chef de DevOps)
2012年7月21日に大崎のフューチャーアーキテクトさんで行われたChef de DevOpsで話してきましたのでその際の資料を公開しておきます。 なお、内容については2011年12月くらいに行ったワンクリックデプロイ勉強会の資料とほとんど同じですので、以前にご覧になっている方にとっては目新しいものは何もありません。 新作作りたかったのですがごめんなさい。 言いたかったことは色々あったりしますが、道具としてのツールを使いこなすのはプロとしてとても重要であるのは前提とした上で、それでも単にツール単体の話をする前に、もうちょっと大きな全体像をとらえる必要があるということです（仕事じゃないなら好きにすれば良いですがね） 目先の効率化ももちろん重要ですが、それがプロダクト全体に対してどう作用するのかというのを理解せずに進めてしまうと、周りの理解も得られませんし、長期的に物事をよりよくするという流れ
pixivのインフラになって2ヶ月がたった - NSEG feat. 高専カンファレンス
pixivのインフラになって2ヶ月がたった - NSEG feat. 高専カンファレンス1 of 22
橋本商会 » Mobage運用技術勉強会に行ってきた
Web公開制限が無いらしいので、殴り書いたメモを貼り付けておく。 謎のアルゴリズムで集められたはてなユーザーに、モバゲーの運用技術を惜しげもなく教える勉強会に行ってきた。 インフラもPerlも全然わかんないんだけど何故誘われたのか謎。 モバゲーすごい・・・台風激しかったけど行ってきて良かった。特にモニタリング手法が面白くて、一瞬だけ全プロセスにデバッガをアタッチして待機状態のプロセス数を調べるとか、DBバックアップサーバーの遅延を監視してるとSlaveへの遅延発生が予測できるとか。頭いい。 たぶんMobageを支える技術に書いてある内容の一部だと思われるので、本も買ってみる。 あと社食で閉店前に「モバゲ〜」って歌が流れててわかめ高校みたいで面白かった。 2012年6月19日 @ DeNA 渋谷ヒカリエの21階 台風きてるからヤバかったらすぐ帰りましょう インフラ部門紹介（小野氏） 世界展開
写真共有サービスslidropの裏側
どうも taka です。 新サービスが公開され楽しくドタバタしてます。 一緒にドタバタしたい人はこちら。 → 仲間募集 【今回、紹介するモノ】 さて、今回は3/6に無事公開された写真共有サービス slidrop で使っているAWSのサービスやソフトウェアを紹介しようと思います。 今回は、コードはいっさいありません！ うんうん だよね！ えっ！こっちの方がいいだろ！ 普通だなぁー とか思って頂ければ。 【そもそもslidropって何？】 slidrop(スライドロップ)は、写真を最大12枚までのslideという1つの塊として投稿できる写真共有サービスです。 iPhoneアプリでは、友人が投稿したslideが縦のタイムラインとして表示されます。 そして、同時に投稿した写真は横方向にスライドする事でみることができます。 という事なのですが、百聞は一見にしかず！ こちらからダウンロードしてみて下さ
DeNA流エンジニア主導ソーシャルアプリ開発秘話 #sac2010 メモ - 130単位
DeNA流エンジニア主導ソーシャルアプリ開発秘話 : ATND http://atnd.org/events/4857 Social Application Seminar on USTREAM http://www.ustream.tv/channel/social-application-seminar フジイさん ソーシャルメディア事業本部 ソーシャルゲーム開発部 2005年ディー・エヌ・エー入社 2009年「セトルリン」開発 現在は新規ソーシャルアプリの開発を担当 内製ソーシャルアプリ 怪盗ロワイヤル、アクアスクエア、セトルリン、戦国ロワイヤル、農園ホッコリーナ、海賊トレジャー アジェンダ 開発について 体制、開発プロセス 開発環境について Flash Liteについて 運用について インフラ構成 負荷対策事例 Yahoo!モバゲーの紹介 内製ソーシャルアプリの開発について 体制
「バックエンドの経験はなかった」Instagram創業者は、どうやってシステムをスケールさせてきたか
昨日のPinterestの記事「Pinterestの急成長を支えてきたアーキテクチャとは？ Pythonで開発しAmazonクラウドで運用」に続いて、やはり写真を中心としたサービスで急成長してきたInstagramのスケーラビリティについて、まとめてみました。 InstagramもPinterestと同様に、基本はAmazonクラウド上でPythonとフレームワークのDjangoを使ったシステムを構築しています。興味深いのは、創業者の二人ともバックエンドの経験がないなかで試行錯誤をしてシステムをスケールさせてきた点です。 Instagramは先月、Facebookに買収されると発表されています。この先、Instagramのシステムはどう変わっていくのでしょうか。 Instagramのシステム構成 約半年前、昨年12月にInstagramのブログに投稿された記事「What Powers In
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
フェイスブックが古い写真のために、フラッシュメモリーを必要とする理由