The Two Sides to Google Infrastructure for Everyone ElseMy talk from Velocity Santa Clara. The format was a debate. Between myself. Looking at the pros and cons around adopting software and practices from oth…
Infrastructure as Code 再考 - Gosuke Miyashita
Infrastructure as Code という言葉が現れてから少なくとも8年ほど経過しており、この言葉もすっかり定着したように見えるが、Martin Fowler 氏が最近自身のブログで Infrastructure as Code について触れており 、また、氏の同僚である Kief Morris 氏が O'Reilly Media から Infrastructure as Code という本を出す（現在 Early Relase 版や Free Chapters が入手できる）ようなので、このタイミングで改めて Infrastructure as Code について、その歴史を振り返るとともに、現在の状況について整理してみようと思い、このエントリを書くことにした。 内容的には、以前書いた インフラ系技術の流れ と若干重複してる部分もある。 そういえば日本でも最近、サーバ/インフラ
Infrastructure as Code の弊害 – Stay Creative !
My name is Rima. And I am a professional Content writer with many years of experience in writing. My primary goal is to solve problems related to writing. And I have been doing it for many years. I have been with several associations as a volunteer and have assisted people in many ways. My love for writing has no end. It is like the air we breathe, something I cherish with all my being. I am a pas
NodeでInfratasterっぽいことができるTasteSpoonというNPMモジュールを作った - Qiita
TasteSpoon 動機 Infratasterは素晴らしいGemで、インフラの振る舞いをコードで表現できることはこの上なくありがたい。ただ、使っていると不便に感じるところもいくつかある。 RSpecにロックインされる RSpecの大量に存在するマッチャAPIで消耗する RSpec2からRSpec3で構文が変わって非本質的な部分で消耗する RSpec上で併用することの多いServerspecとコンテクストが混ざる RSpecでは待ち合わせの概念が入ると途端にコードがダサくなる 最後の「待ち合わせ」だけ補足すると、これはWebSocketなどの通信が確立することを確かめたい場合が例としてあげられる。infrataster-plugin-socket.ioを作った際、通信が確立できることを確かめるのに、こういうダサいコードを書くことになった。 タイムアウトの概念が存在して、マッチャAPIがシ
Immutable Infrastructure: No SSH
Deploy your JVM, Node.js and Go apps to AWS. Effortlessly. Build minimal fully-provisioned images in seconds. Test on VirtualBox, deploy atomically to AWS. No legacy OS. No containers. No drift. Start Deploying Effortlessly Minimal Images CloudCaptain generates minimal images for your application in seconds. They boot directly on virtual hardware. There is no classic OS and no container runtime. I
confdでちいさく始めるインフラ構築の自動化 - Qiita
はじめに 最近ではInfrastracutre as codeやImmutable Infrastructreの考え方によるインフラ管理が浸透してきました。 ChefやAnsibl、最近ではItamaeといったプロビジョニングツールの選択肢が増えてきとはいえ、未だに敷居の高さを感じ導入に踏み切れていない方も多いのではないでしょうか。 そこで今回はお手軽に始められるインフラ構築ツールとしてconfdについてまとめてみました。 confdとは goで書かれた設定ファイル管理ツールです。 kelseyhightower/confd 主要機能は設定ファイルのテンプレートエンジンなのですが、設定ファイルの生成前後で外部コマンドを実行することが可能です。 そのため 設定反映のための前処理 設定ファイルの自動生成 設定反映のためプロセス再起動 といった一連の作業を担わせることができます。 また、構成もシ
hb-agent - 構築・監視項目検出自動化ツール hb-agentのご紹介
こんにちは。斎藤です。 私の記憶では2012年頃から盛り上がり始めた、ITインフラ構築・運用の自動化やコード化のお話ですが、その後みなさまどのような形で推進されていますか？あれから3年ほど経ちまして、当社でも取り組んできた内容を一旦棚卸しできるかなと考え始めています。そうそう、「MSPでのChefの使い方 --- 運用ノウハウをコードに落とす」という記事を書いた日から考えても、2年以上経っています。 そこで、何回かに分けまして、私が担当していたITインフラ構築・運用の自動化・コード化に関する取り組みについてご紹介していきます。 TL;DR hb-agentは、「初期構築作業の自動化」「監視項目洗い出しの自動化」そして「ノウハウをコードに集約」を実現する社内ツールです。 導入を通じて、構築時間の短縮、ノウハウの共有がすすみました。その結果、新しいスタッフが入った時でも習熟度のぶれを押さえ、構
クックパッドのサーバプロビジョニング事情 - クックパッド開発者ブログ
インフラ部の荒井（@ryot_a_rai）です。この記事ではクックパッドで利用しているプロビジョニングツール "Itamae" の紹介と細々した Tips を紹介します。 式年遷宮とプロビジョニングツール 現在、弊社ではインフラの式年遷宮*1を進めています。式年遷宮以前、弊社では Puppet を利用してサーバをセットアップしていましたが、式年遷宮に際して既存のプロビジョニングに関するコードは捨てることになるため、プロビジョニングツールの再検討を行うことになりました。 Puppet, Chef, Ansible, SaltStack を検討した結果、 言語特性の観点では、Ruby DSL な Chef が良い アーキテクチャ・エコシステムの観点では、シンプルな Ansible が良い といった点から、どれも決め手に欠ける状況で、Ruby DSL で記述できるシンプルなプロビジョニングツール
ソフトウェアエンジニアだけでサービス運用できる環境を作って失業した話 - まいんだーのはてなブログ
はじめに このエントリは非常にポジティブで技術的なチャレンジに関するまとめであり求人エントリでもあります。 まとめ 昨年後半から、急成長するサービスを支えるため “どオンプレ” な環境で作ったサービスをクラウドに持っていく仕事をしていました。 クラウドのオイシイところを押さえられるよう作り変えをした結果として “Infrastructure as Code” を実践することになり、結果としてソフトウェアエンジニアだけですべてがコントロール出来る状態になり、インフラおじさん業が不要になりました。 そういった環境で働きたい "腕の立つITエンジニア(特にスマホとサーバサイド)" を募集しています。 発表資料&箇条書きで振り返る最近の動き AWS Casual Talks #3 https://github.com/myfinder/aws-casual-3/blob/master/slide.
ツール普及のために社内ハンズオンに取り組んでみた
こんにちは。斎藤です。 ハートビーツはMSP、即ちITインフラの構築・運用・及びコンサルティングを生業としています。その中で、数年前からソフトウェアを利用した業務自動化・効率化(Infrastructure as Code、以下IaC)を推進しています(※1)。 さて、IaCを推進するにあたって、様々なソフトウェアを開発、及び導入します。その際、どのように普及させるかはいつも頭を悩ませる問題です。そこで、今回は私がツール普及のために取り組んできた事、特に社内ハンズオンでの取り組みを、「ツール普及のための手段の検討」「ハンズオンの流れ」そして「実際に取り組んでみた結果」の3点をお話します。 ツールを普及させたいのだけれど、いまいちうまくいかない...という方へ、少しでも力になれれば幸いです。 ツール普及のための手段の検討 きっかけは？ 新しいツールが出てきたとき、読者の皆さんは何をきっかけに
急成長するサービスのサーバインフラ - ワザノバ | wazanova
サービスを一から立ち上げる場合も、成功したサービスが更に拡大する場合も、いずれもスケールさせるのは一苦労ですが、今回は、Dropboxの初期の取組みと、Facebookの最近の動きを取り上げてみます。 まずは、DropboxのKevin Modzelewskiが、創業当初のサーバインフラの進化を時系列で紹介している講演から。 Dropboxのデータの特徴 書込みボリューム大: 通常のサービスはコンテンツをつくるより消費するボリュームが圧倒的に多いので、read/write比率が、100:1とか1000:1であるのが典型だが、Dropboxはユーザの全端末がコピーを持つ構造なので、その比率が約1:1になる。つまり、同じサーバに対して、他社よりも100倍、1000倍書込みの役割が大きくなる構造。 ACID特性の要件をしっかり守る必要がある。ユーザの情報を預かるのだから、原子性について、「大きな
Reverse Proxyがなぜ必要か、勝手に補遺 - たごもりすメモ
「全体のリソース効率を上げましょう」というためのものである。 Reverse Proxy がなぜ必要か - naoyaのはてなダイアリー これは完璧に正しくて、ただ「リソース効率」という概念はあまり具体的な想像が追い付かない人がいそうだなと思ったので、ちょっとだけ補足しようと思った。 Reverse Proxyを入れることでリソース効率の向上を狙うんだけど、それは以下のような複数の場面におけるそれぞれのリソース効率向上を複合的に狙うものだ。 通常時のトラフィック配信におけるCPU・メモリ使用率を最適化する バースト時(過負荷時)のトラフィックをより細かく制御可能とする 障害時におけるダウンタイムおよび総合的な計算・配信能力の低下を極小化する 多数のサーバによる構成全体を増強・入れ替え・移動あるいは削減する際の自由度の向上を狙う 簡単にコンピュータの性能だけで言うと最初の項目だけをリソース効
最新インフラエンジニア技術勉強会に行ってきました #dli_infra | こえむの編集後記
昨夜、ドリコムさんで行われた「最新インフラエンジニア技術勉強会 〜Fluentd, Elasticsearch,Chefの実践実例〜」に足を運んできました。 タイトルにもありますように、Chef, モニタリング, Fluentd, そして elasticsearch が使われている現場の情報を伺える機会となりました。 それでは、いつものようにノートをアップしておきます。 概要 2014-05-23 ドリコム 本社 (目黒アルコタワー) 19:30-20:00 ひらしー ドリコムのInfrastructure as Code 20:00-20:30 mickey Winning the metrics battle 20:30-21:00 外山 寛 Fluentd プラグイン開発講座 21:00-21:30 yoshi_ken MySQLと組み合わせて始める全文検索エンジン「elastics
急増するLINEインフラの課題と対応 « LINE Engineers' Blog
こんにちは。今回はITサービスセンターより、インフラ運営の観点から急増するLINEインフラの課題と対応について記させていただきます。 はじめに 先日開催したLINE Developer Conference（インフラ編）には大勢の方にいらしていただきました。カンファレンスでは、LINEサービスが始まってから約2年の間に我々はどういった方法でインフラ運営を行い、またどんなことに悩んできたのかを、システム、データベース、ネットワークの観点からそれぞれ発表させていただきました。 カンファレンスはLINE株式会社が様々な技術をどのように使い、どのように運用を行っているのか。現在どのような技術的なことに取り組んでいるのか日本のエンジニアの皆さんに知っていただくために開催されました。結果としてインフラ編では150名の定員に対して430名のご応募をいただいたとのことでLINEサービスに対する関心の高さを
LINE Developer Conference(テーマ：インフラ)にいってきたメモ - 目の前に僕らの道がある
昨日(2014/04/15)にLINE Developer Conferenceに参加してきました。 寝かすと、永久に書かない気がしたので、消化し切れてないけど、メモ書きだけ残しておきます。 LINE Developer Conference 開催のお知らせ http://line-hr.jp/archives/37147547.html 今まで、LINEのインフラ回りがどうなっているのかってあまり情報を見たことなかったので、興味深く聞けて面白かったです。 普段関わっているサービスとは全然規模が違い、世界展開するサービスならではの話などとても面白かったです。ネットワーク回りで、昔ちょろっと触っていたMPLSの単語が出てきて懐かしかった。 いろいろ話を聞いていて、LINE社は面白そうな技術を使っていてるので、こういう会社で働けるとすごい楽しそうですね。 こういう機会がまたあったら是非参加した
Developers Summit 2014 で「サーバプロビジョニングのこれまでとこれから」という発表を行いました - Gosuke Miyashita
内容自体は基本的に、第5弾 週末ランサーズ にお邪魔した時に お話した資料 と同じなんですが、この時よりも時間が少し長かったので、多少内容を追加しているのと、当時自分の中でうまく整理できてなかったけど、今は多少クリアになった部分もあって、そういった内容を盛り込んだりしてみました。 Togetter まとめ NAMIKAWA さんによるまとめ 一点お詫びしたいのは、登壇者に質問ができる Ask the Speaker というコーナーがあって、セッションが終わった後はそちらに移動、という段取りだったのですが、裏でやっていた OSS コミッタ大集合 の方でも登壇するために終了後すぐに E 会場に向かったため、Ask the Speaker コーナーに行けませんでした。もし質問するためにいらしてくださった方がいましたら、本当に申し訳ないです。 今回デブサミに登壇させて頂いた経緯については、会場で
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Status.io - Hosted Status Pages
Mark Burgess Website