Reverse Proxy がなぜ必要か - naoyaのはてなダイアリー
フロントエンジニアに知ってもらいたいリバースプロキシの重要性 | RickyNews この記事が目に入って読んでみた。なるほど、昨今は Reverse Proxy は便利な L7 ルーター的なものとして認識されているのだな、と思った。URL の Rewrite や、VirtualHost 云々。確かに Reverse Proxy の便利な側面ではある一方、それらは Nginx などの Reverse Proxy でなければ実装が不可能かと言えばそんなことはないものでもある。 自分は Reverse Proxy はもうすこしサーバー/インフラ的な側面でその役割を捉えている。今更何をというものでもあるが、昼休みがてら時間があるので簡単に書いてみよう。 Reverse Proxy はWebシステム全体のリソース最適化のためのパーツ Reverse Proxy のインフラ的な視点での役割は「Web
ウェブアプリケーション開発に新言語を採用したときにインフラで考えたこと - ゆううきブログ
この文章は、サーバサイドのウェブアプリケーション開発において、社内実績の少ない新しい言語を採用したときにインフラ面で考慮したことを社内向けにまとめたものです。 はてなでは、長らくPerlでウェブアプリケーション開発を続けてきた一方、ここ数年で社内でScalaまたはGoの採用事例も増えてきました。 今後開発が始まるプロダクトにおいても、Perl、Scala、Goもしくは他の言語を採用するかどうかを開発開始時に選ぶことになるでしょう。 新言語を採用するときに、考慮すべきことの一つとして、「インフラ」への影響があります。 新言語に関する雑談をしていると、ウェブアプリケーションエンジニアに「インフラ」への影響について聞かれます。 もしくは、ウェブオペレーションエンジニアから考慮するポイントを伝えることもあります。 ScalaやGo以外に、Node.jsやサーバサイドSwiftはどうかというのも雑談
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 について、その歴史を振り返るとともに、現在の状況について整理してみようと思い、このエントリを書くことにした。 内容的には、以前書いた インフラ系技術の流れ と若干重複してる部分もある。 そういえば日本でも最近、サーバ/インフラ
これだけはやっておきたい〜マイクロサービスのデプロイメント - クラウドワークス エンジニアブログ
Scala大好きインフラエンジニアの九岡(@mumoshu)です。マイブームはConcourse CIですが、今日はマイクロサービスの話をさせていただきます。 TL;DR; 「サービスの負荷上がってきたし、マイクロサービス化しよう。マイクロサービス化って、Railsアプリ分割して、それぞれCapistranoでデプロイしておけばいいんでしょ？」*1 マイクロサービス化をするためには、アプリケーションだけでなくインフラや運用のことも考える必要があります。 この記事では、クラウドソーシングのクラウドワークスが来るマイクロサービス化に向けて認識しているデプロイメント上の問題とその対策を紹介します*2。 テストからデプロイまでがめんどくさいよ問題 →Dev/Prod Parity、Infrastructure as Code、CI、ビルドパイプライン リリースに1時間かかるよ問題 →ビルドキャッシ
他のチームに｢技術的支援｣をする時に気をつけていること - Masteries
自分が働いているGaiaxのように, 社内に複数の事業があり, それぞれにエンジニアが所属して働いている場合, ｢ねえ, ○○のチームの××って仕組み, どうやってるの? うちのチームでもやってみたい!｣といったコミュニケーションから, 他のチームに対して｢技術的支援｣をする機会が生まれる事が多々あります. 最近の例だと, 社内の新規事業の立ち上げや, オンプレからクラウドへの移管のタイミングで, Infrastructure as Codeやデプロイ施策, ChatOpsなど整えたいので, 相談に乗って欲しい! という声を何度か頂いた事がありますし, よくよく考えると今やっているPhotosynthへの留学も, 見方を変えれば｢Photosynthへの技術支援｣と言えるかもしれません. そういった｢技術的支援｣をする時に気をつけている事についてFacebookにつぶやいた所, 思ったより
私は Infrastructure as Code をわかっていなかった - メソッド屋のブログ
私はここ１週間ほど、同僚の David の一言で Infrastructure as Code について頭が大混乱状態でした。 それは次の一言です。 Chef や Puppet は大体の部分は Infrastructure as Code じゃないよね。ARM (Azure Resource Manager) はそうだけど。 ただ、Chef-Provisioning は Infrastructure as Code だよね。 もう頭が大混乱です。なんとなく言わんとしていることはわかりますが、私は今まで Chef とか、Puppet とか、Ansible とかで やっているようなことが、Infrastructure as Code と思い込んでいましたが、何か間違っていたのでしょうか？そういえば、 Chef はConfiguration Management Toolと紹介されていたなとか頭
継続的デプロイ実現のためにはインフラの考慮が必要という話
全国1000人のスタックフルエンジニアのみなさんこんにちは。 DevOps.comでのRe-thinking DevOps tools for Continuous Deployment successという話が興味深かったのでご紹介します。 ここで話しているのはいわゆる大きな組織においてデプロイやプロビジョニングを自動化しようとしたときにぶちあたるインフラ面でのブロッカーの話と捉えてよいでしょう。 十分な開発環境がない、開発環境のリソースの制限がきつい、本番環境と開発・テスト環境があまりに異なるといった話をよく聞きます。しかし、新しい機能を作って届けるためのサイクルタイムを短くしようと思うなら、開発プロセスだけを改善しても始まりません。速度を遅くするブロッカーが何なのかをとらえた上で、それがインフラ周りであればそれも改善しないといけません。 以下勝手訳です。 継続的デプロイ成功のためのD
WEB系各社で使われている監視ツールまとめ - mikedaの日記
次世代 Web カンファレンスで監視について話すことになったので、ネタとしてWEB系各社で使っている監視ツールを調査中。 うちはこれ使ってるよ！！！ってのがあったら@mikedaにメンションください！ Cookpad Zabbix 昔はNagios+muninだけど台数増えて性能的に破綻した ビューはそのままじゃ辛いのでmunin風に表示するのを自作 StatusCake DataDog。サービス系、サーバに紐付かない系の監視に。DashBoard便利 waker。通知用。PagerDuty高い、と言ってryot_a_raiが秒で作ったらしい Kibana imon。独自のリアルタイムなサービス稼働状況表示ツール NewRelic 試し中なもの Real-User Monitoring : JSでbeacon飛ばしてfluentd -> BigQuery。Google SpreadShee
ビッグデータツールチェインのセキュリティはビッグリスク、あるいは、誰もHadoopをスクラッチからビルドする方法を知らない件について
ビッグデータツールチェインのセキュリティはビッグリスク、あるいは、誰もHadoopをスクラッチからビルドする方法を知らない件について The sad state of sysadmin in the age of containers コンテナー時代のシステム管理者の惨状 システム管理は惨劇に見舞われている。現状は悲惨だ。 筆者は昔気質のシステム管理者に不満はない。システムの稼働を維持し、アップデートし、アップグレードする方法を知っている者達だ。 この憤りは、コンテナーと構築済みVMと、それらがもたらす、「信頼」や「アップグレード」の欠如による悲惨な惨劇に対するものだ。 例えば、Hadoopを見てみろ。誰もHadoopをスクラッチからビルドする方法を知っているようには見えないぞ。依存性とバージョンとビルドツールが悲惨なほどに絡まりあっている。 この手のイケてるツールの中で、古典的なmake
Serverspec本を読んで、先鋭化されつつあるWeb系インフラエンジニアを知る - Glide Note
Serverspec Serverspecを執筆されたmizzyさんからご恵贈頂きました。ありがとうございます。 本書の詳細な紹介はあんちぽさんのブログと、mizzyさんが出演したRebuildがオススメです。 Serverspecの作者がつくる、あるひとつのOSS文化 - 書評『Serverspec』 - delirious thoughts Rebuild: 75: Book Driven Development (gosukenator) 事前に断っておくと私がここで記載している「インフラエンジニア」はITインフラエンジニアの話です。 以前サーバ/インフラ徹底攻略を本ブログで紹介したあとに、 書内のある特集を執筆担当された方と話していて、 Web系インフラエンジニアがどんどん先鋭化されつつあって、この本の内容を理解出来る人ってどれくらいいるんだろうね という事を仰っていたのが非常に印
インフラの継続的デリバリー - naoyaのはてなダイアリー
事前に断っておくがここでいう「インフラ」はレイヤ的には OS より上の話。 少し前に GitHub 時代のデプロイ戦略 - naoyaのはてなダイアリー で、GitHub を介したデプロイを実践しているということを紹介した。普段の開発を Pull Request ベースでやっているので、デプロイもまた Pull Request を契機に実行させると色々捗る、という話。 このプラクティスの対象領域をインフラにまで拡大してみました、というのが今回の話。 DNS レコードを Pull Request を merge した契機に自動で更新 AWS を利用している場合、ドメインの管理も Amazon Route 53 を使うといろいろと都合がいい。 Route 53 での DNS レコードの更新はこれまでブラウザから操作していた。これだと誰がいつ作業したかわからないし履歴もトラックしづらい。また変更
最近の仮想化界隈を知る：VMWareからCoreOSまで | 射撃しつつ前転
仮想化の分野はどんどんと新しいものが出てくる。全部を実際に試すことは出来なくても、筋が良さそうなものについては、どういうものなのかある程度把握しておきたい。最近はちょっと忙しくてあまり情報収集ができてなかったので、追いつこうと思ってちょっと調べてみた。 ハイパーバイザ型仮想化とコンテナ型仮想化 仮想マシンの歴史をたどると、メインフレームの方では随分と昔から使われている技術である、と出てくる。一方で、x86の世界ではそれほど歴史は長くなく、1999年にリリースされたVMwareがおそらく実用的な初の仮想マシン技術だろう。 VMWareはハイパーバイザ型仮想化と呼ばれる技術で、上に乗るOS（ゲストと呼ばれる）に対して仮想的なハードウェアを提供する。ハイパーバイザ型も、どのレイヤで仮想的なハードウェアを提供するかで更に細分化されるらしいが、よく知らないので、ここではそこまでは踏み入らない。ハイパ
式年遷宮Infrastracture · さよならインターネット
August 11, 2013 Immutable Infrastracture について / apatheia.info こちらのエントリーを読んでふと思いついたので書きました。 式年遷宮 / 伊勢神宮 今年、伊勢神宮は20年に一度の式年遷宮の年なのだが、 このシステム、今のインターネットのインフラストラクチャの モデルとして結構参考になるのではないだろうか。 さすがに20年間無停止で動いているサーバは その存在自体が重要文化財になってしまうが、例えば、１つのシステムを ロードバランサ、スイッチ、サーバ、ミドルウェア、ログ集約サーバなど 完全に冗長化しておき、１週間毎に冗長化されたシステム、A、Bをそれぞれ入れ替える。 このアーキテクチャを採用した場合、 アプリケーションの大規模な改修が発生した場合にも スタンバイ側となっているインフラストラクチャ側で スナップショットのようなものを取得
エンタープライズから見たImmutable Infrastructure - arclamp
Immutable InfrastructureとかDisposable ComponentsとかBlue-Green Deploymentが話題になってるみたいで。 Immutable Infrastructureはアプリケーションのアーキテクチャを変えていく、伊藤直也氏（前編） － Publickey Immutable Infrastructureはアプリケーションのアーキテクチャを変えていく、伊藤直也氏（後編） － Publickey 詳しくは記事を。「不変のインフラ」つまり、一度動くようになったサーバーには手を触れず、なにか変更が発生したら新たなサーバーを別途構築し、丸ごと入れ替えることでシンプルな管理が可能になるというもの。「インフラ設定を自動化する」という流れとして見ると非常に面白い。 言いかえれば「アプリからインフラまでを一貫して構成管理する」ということになると思います。ソ
最近のImmutable Infrastructureに関する議論(Orchestration編) - Kentaro Kuribayashi's blog
この分野について議論する際には、インフラ系技術の流れ - Gosuke Miyashitaで紹介されている Bootstrapping Configuration Orchestration という整理を前提に議論すると、どのレイヤについて話しているのかごちゃごちゃにならなくてよいと思う。ただ、 上記は階層を成す概念なのだけど、それぞれが必ずしも排他的ではなく、重なる部分が多々ある(たとえば、(1)に該当するDockerやPackerにも(2)の要素が含まれている等) Orchestrationというネーミングがいまやミスリーディング(な面がある) ということもあって、一部に混乱をきたしている。ここでは、特に(2)について、時系列を追って論ずる。 時系列の整理 インフラ系技術の流れ - Gosuke Miyashitaによる整理 Rebuild: 25: Immutable Infrast
Immutable Infrastructureに対する自分なりの考えメモ - $shibayu36->blog;
インフラ系技術の流れ - Gosuke Miyashita 今さら聞けない Immutable Infrastructure - 昼メシ物語 2014年のウェブシステムアーキテクチャ - stanaka's blog http://rebuild.fm/25/ この辺りを読んだ。自分の中ではImmutable Infrastructureについてはここ一週間で調べただけであり、解説などは出来ないが、とりあえず自分用のメモとして自分の思ったことなどを書いていく。 コンテナベースのデプロイ Dockerなどが出てきたことにより、Dockerのイメージをそのままアップロードし、それを本番でも動かすということが出来そうというのが面白かった*1。こういう風なフローになるとすると、これまでのデプロイ手順とは全く違うようになりそう。 これまでのデプロイと、コンテナベースのデプロイ これまでのデプロイは
ポータブルなWebアプリケーション - naoyaのはてなダイアリー
140文字で書ききれなかったのでブログに殴り書き。 Heroku のアプリケーションを人に渡す 昨日、「naoyaさんが作ってるiOSアプリのバックエンドサーバーに相乗りさせてもらえないか」という話をいただいた。自分でも同じようなAndroidアプリを作っているけど、サーバーサイドは作ってないからということらしい。 対して「githubにコードあるからgit cloneしてheroku pushすれば動くし、自分で heroku にデプロイしてよ」と応えた。相乗りしてもらってもよかったのだけど、こちらでコードを書き換えたりメンテしたときに先方のアプリが停止することを考えると同じコードベースでサーバーは自分で立ててもらう方が何かと良い。 対象になったソフトウェアは Heroku で動かしていたので、Heroku Ready な形、つまり、必要な外部パッケージの一覧やサーバーの起動手順なんかは
今さら聞けない Immutable Infrastructure - 昼メシ物語
Immutable （不変な） Infrastructure は、サーバを一度セットアップしたら二度と変更を加えないという運用スタイルのことを指します。 クラウド環境では、必要に応じてすぐにサーバを用意し、不要になったら簡単に破棄することができます。Immutable Infrastructure は、このようなクラウドの特性を活かす運用スタイルとして、注目されつつあります。 背景 Immutable Infrastructure が提唱された背景にある技術として、 Auto Scaling や Blue-Green Deployment*1 などがあります。 Auto Scaling Auto Scaling は、負荷に応じて自動的にサーバ台数を増減させる技術で、 AWS では標準で提供されています。常に必要な台数だけ起動していればいいので、コスト削減になるというものです。 Auto S
2014年のウェブシステムアーキテクチャ - stanaka's blog
(Monitoring Casual Talk in Kyotoで発表してきたので、ブログエントリにまとめ直しました) 2013年はインフラ周りの技術的な進化が大きく、いくつかのエポックメイキングな概念と実装が産まれました。個人的には特に以下の2つが大きいと思っています。 AWSの本格普及期 DockerとImmutable Infrastructure これらを踏まえて、2014年のウェブシステムの進化の方向性を考えてみます。また、それによるモニタリングへの影響もあわせて考えます。だいぶ長くなってしまったので、急ぐ人は最後に結論をまとめましたので、そちらからどうぞ! 2013年という時代背景 AWSが本格普及期を迎えているのは、言わずもがなのことで、Re:Inventでの246件という膨大のセッション数などにその勢いが表われています。 また、DockerはLXC (LinuX Conta
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
