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 について、その歴史を振り返るとともに、現在の状況について整理してみようと思い、このエントリを書くことにした。 内容的には、以前書いた インフラ系技術の流れ と若干重複してる部分もある。 そういえば日本でも最近、サーバ/インフラ
GCEのライブマイグレーションのすごさをまとめてみた #gcpja - Qiita
Google Cloud Platform (GCP)の英語ブログに、Google Compute Engine (GCE)のライブマイグレーション機能について解説記事がポストされた。個人的にもいくつかの大規模な案件でこの機能の能力に触れて、GoogleまじGoogleだなと思わされたし、GCPチームで実際に作った人たちと会うととても誇らしげに説明してくれる。熱いのだ。そこで、上記ブログ記事＋個人の経験をもとに簡単にまとめてみたい。 なお、以下の内容は個人の感想です！ Heartbleedバグの時もVM再起動なし GCEでは2013年12月より、ライブマイグレーションを利用したTransparent Maintenance（自動メンテナンス）という運用を開始している。これはつまり、VMを動かしたまま同一ゾーン内の別のサーバーへ移動することで、ハードウェアやホストOSのメンテナンスを勝手にや
JenkinsとPuppet+ServerspecでインフラCI / Jenkins Puppet Serverspec Infra CI
Jenkins ユーザ・カンファレンス 2015 東京 – セッション
『TOTEC2014 インフラチューニング（チューニンガソン）で優勝したはなし』
TOTEC2014 インフラチューニング（チューニンガソン）で優勝したはなし | サイバーエージェント 公式エンジニアブログ インフラ＆コアテク本部の仲山です。 「TOTEC2014 インフラチューニング」という社内チューニンガソンイベントで優勝をいただいたので、 技術ブログを書くことになりました。 TOTECは、サイバーエージェントグループ内の技術者コンテストで、 インフラ、フロントエンド、サーバサイドの分野ごとに、 「チューニンガソン」と呼ばれる形式でその速度向上を競い合います。 今回の「インフラチューニング」では、 参加者はソフトウェアのソースコードを改変できないため、 あくまでミドルウェア等の変更、チューニングや、サーバ構成の最適化のみで闘います。 主なレギュレーション 運営があらかじめ用意したMediaWikiの応答速度を競う。 ソースコードの変更は禁止だが、設定ファイルの編集は
ChatOpsでOSのセキュリティアップデートを自動化出来るようにした - Glide Note
先日@naoya_itoさんが自身のブログ(インフラの継続的デリバリー)でKAIZEN platform Inc.のインフラについて書いていたやつの続編的な内容。 TL;DR Chat(Slack) + Hubot + CircleCI + GitHub を用いてセキュリティアップデートを自動化した GitHubのPull Requestを契機にセキュリティアップデートを実行できるようにした CircleCIが大変便利。インフラ系の作業を自動化するのに非常に合っている気がする 背景 KAIZEN platform Inc.では、 ネットワーク脆弱性スキャン アプリケーション脆弱性スキャン セキュリティアップデートの定期実行 の3つをセキュリティ系タスクとして継続的にやっていこうという話になり、今回は私が担当した、「セキュリティアップデートの定期実行」の話。 RHEL系OSにはyumの自動更
Immutable Infrastructure / これからのWeb, クラウドシステム
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
BOOTHの話 pixiv-summer-intern2014 // Speaker Deck
pixivが運用しているBOOTHの構成などについて
インフラエンジニア不在で120万人のユーザーを支える方法 - Eureka, Inc.
はじめまして、WEBエンジニアの石橋です。 エウレカではpairs全体の開発責任者としてサーバサイドの開発・管理、インフラの構築・管理を行っています。また、数字やリソースの計画・管理など一部プロデューサー業務も担当しています。 前々職では受託のWEBエンジニアを4年、前職では自社サービスの基幹システムやECシステムのインフラ構築・開発などIT部門の統括、物流・CS部門の統括、自社メディアのプロデューサーとしてマルチタスクな4年間を過ごしていました。 趣味は漫画を読むことです、が最近インフラ周りに時間を取られてなかなか読めていません。。漫画が読めない時間が長く続くと、自分の中の何かのエネルギーがどんどん減っていきいずれは枯渇するような気がしてなりません。1分でも多く漫画を読む為にも、まずはしっかりインフラを整備せねばと今日も仕事に励んでいます。 さて今回は初めての投稿ですので、まずは先日会員
KAIZEN platform Inc. における運用自動化
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
柔軟な IT インフラとそれを支える技術 | GREE Engineering
こんにちは、インフラストラクチャ本部の大山裕泰です。最近話題の WhiteBox スイッチと、そのミドルウェアについてお話したいと思います。 柔軟な IT インフラを目指して 我々に限らず IT インフラに携わるエンジニアにとって、アプリケーションレイヤの人たちが望むアプリケーション実行環境の構築・運用は主要な目標の一つかと思います。 アプリケーション実行環境の形態は様々ですが、突き詰めてゆくと物理的なネットワーク機器に Ethernet ケーブルで接続された物理サーバの集合になります。やや管理的な話になりますが、こうした物理機器は減価償却してゆくので、これが終了するあるいはサポートが切れるまでの 4～5 年の期間、同じ機器を使い続けることになりますので、機器の選定においては長い目で見る必要があります。 これに対して、アプリケーションやアプリケーションを取り巻く環境は日々目まぐるしい速度で
ヌーラボのインフラ運用最前線 〜イミュータブルを目指して〜 (後編) | 株式会社ヌーラボ(Nulab inc.)
私たちの元々の目的は「イミュータブルインフラストラクチャ」を構築する事ではなく、前編で紹介した課題を解決するための運用フローを構築することでした。それを開発のフェーズからコツコツと模索した結果として「イミュータブルインフラストラクチャー」に少しずつ近づいている、というのが正直なところです。
急増するLINEインフラの課題と対応 « LINE Engineers' Blog
こんにちは。今回はITサービスセンターより、インフラ運営の観点から急増するLINEインフラの課題と対応について記させていただきます。 はじめに 先日開催したLINE Developer Conference（インフラ編）には大勢の方にいらしていただきました。カンファレンスでは、LINEサービスが始まってから約2年の間に我々はどういった方法でインフラ運営を行い、またどんなことに悩んできたのかを、システム、データベース、ネットワークの観点からそれぞれ発表させていただきました。 カンファレンスはLINE株式会社が様々な技術をどのように使い、どのように運用を行っているのか。現在どのような技術的なことに取り組んでいるのか日本のエンジニアの皆さんに知っていただくために開催されました。結果としてインフラ編では150名の定員に対して430名のご応募をいただいたとのことでLINEサービスに対する関心の高さを
シリアルコンソールを極めよう - Part1. 概要編 - インフラ寺子屋ブログ
2014-05-03 シリアルコンソールを極めよう - Part1. 概要編 ナレッジ 今回から7回に渡って、シリアルコンソールについて解説していきたいと思います。 「え、シリアルコンソールでそれだけ話す事あるの？」と思われるかもしれませんが、実はあります。 実際はそれほど難しいものではありませんが、一度きちんとノウハウをまとめたものを作りたいので、書いていこうと思っています。 シリーズ一覧 →シリアルコンソールを極めよう - Part1. 概要編 シリアルコンソールを極めよう - Part2. USB変換ケーブル編 シリアルコンソールを極めよう - Part3. 変換コネクタ編 シリアルコンソールを極めよう - Part4. ケーブル編 シリアルコンソールを極めよう - Part5. ターミナル編 シリアルコンソールを極めよう - Part6. コンソールサーバを自作しよう
Immutable Infrastructure #jawsdays
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
第4章 インフラ構成管理の改善～実サービスでの歴史から学ぶ、段階的な負債返済 | gihyo.jp
インフラにおける改善の実際 本章では実在するサービスを題材に、インフラの改善で取り組んできたことを紹介します。 ヘテムル 執筆陣が関わっているpaperboy&co.（以下、ペパボ）のサービスは「ヘテムル」です。ロリポップ！ と並ぶレンタルサーバのラインナップで、大容量・高負荷に耐えうる上位のサービスとして提供しています。2005年リリース当初はサーバ数十台でしたが、それから規模や機能も増え、2013年5月現在は400台弱の規模にまで成長しました。執筆陣は4年前の2009年からヘテムルに携わっており、運用と機能改善を行っています。 インフラの技術的負債 インフラの技術的負債には次のものがあります。 a．集中管理されていない設定情報によるサーバごとでの微妙な仕様差 b．すばやい変更手段を持たないことによるサーバ全台展開の手間 c．移り変わるハードウェア性能とそれを扱う運用の柔軟さがないことに
Aimingデータ解析チーム現場だより - Qiita
ホゲェ〜 なんか色々とまとめといた方が良さそうだ。 自分にとって数が多くて意味がわからんし。 まだ社内データは収集する環境を整えている状態だ。 整えているといってもできてるんだけど、 なんか色々と新しいツールが出てくるしそれに追っついて 書き換えちゃったりを繰り返している。 意味がわからなくなってきたのでまとめてみよう。 社内で共有するにはQiitaに上げたほうが良さそう。 あげちゃまずいものは書いてないつもりだ。 まずかったら消す。 データ解析チームが何やってるのかをまとめてみた。 各担当者の名前を出して問題なさそうなら出そうかなあ Aimingデータ解析チームについて データ解析チームだとつまらんし愛情がわかないのでチーム名をつけている。 Monolithだ。モノリス。あのモノリス。 @shibacowさんが考えだした。トテモ良いチーム名だと思う。 チームメンバー は以下の3名 @sh
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ドリコムのInfrastructure as code
突然ITインフラを任された人のための…監視設計入門 #yapcasia
20140419【qpstudy】OSとNW設計の勘所
Future of Server Provisioning at Developers Summit 2014
