サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに この仕事を始めた当初(約20年前)はオンプレミスという言葉がありませんでした。いや厳密には私の周りではパブリッククラウドとオンプレミスを分けて話す人はおらず、インフラ構築といえば今でいうオンプレミスが中心でした(世の中的にはパブリッククラウドがサービスとして存在していました)。オンプレミスみたいに新しい概念が出てきた時にそれまでの概念を説明するためにできる言葉をレトロニムというそうです。 私が本格的にパブリッククラウドの仕事をし始めたのは約3年前でAWSでした。研修ではAzureを先に触れていたのと、この本を読んでいたという知
ソフトウェア開発、ITインフラ運用、そしてその境界線上にあるトピックをカバーし、特にDevOpsを実現するための自動化、テスト、セキュリティ、組織文化にフォーカスした「DevOpsDays」。ここでソフトウェアエンジニアのチェシャ猫氏が「Infrastructure as Code の静的テスト戦略」をテーマに登壇。まずはInfrastructure as Codeについてと、そのつらみから発生する“オートメーション恐怖症”を防止する方法を紹介します。 「コード化の“つらみ”をいかにうまく防ぐか」が今日のテーマチェシャ猫氏：チェシャ猫と言います。Twitterは@y_taka_23の名前でやっているので、よろしくお願いいたします。今日は「Infrastructure as Code の静的テスト戦略」をテーマに選びました。Infrastructure as Codeはここ数年で、非常にメジ
電力不足やべえやべえって言われてますが、具体的に何がやばいかって話が可視範囲でどこにも見かけないので、新電力業界きらいなはてな民向けにその辺を説明するよ。 前提１…電力自由化で自由化されたのは「小売」だけインフラに市場原理を導入したことに批判が集まりがちだよね。本質的にはそのとおりなんだ。でも建前上は「インフラは自由化してない」んだよね。 電力業界は2016年4月に小売が自由化したよ。どういうことかというと、電力事業を「発電」「送配電」「小売」に分割しちゃおうってことなんだよ。たとえば東電は東電ホールディングスになって、その下に東電パワー＆フュエル（発電）、東電パワーグリッド（送配電）、東電エナジーパートナー（小売）の子会社ができたんだよ。 なんでそうなったかは色々な経緯があるというか、「原発でやらかした東電をなんとかせげんといかん！」って気持ちがあったのかもしれないね、と思ってるよ。でも
こんにちは、はじめまして。さくらインターネット株式会社の長野雅広（@kazeburo）です。Webの業界に入ったのは学生だった2000年頃で、キャリアは20年以上になります。おそらくこの業界でも長い方ではないでしょうか。20年の間にmixiやlivedoor、メルカリといった企業で働く機会を得て、どの職場でもサービスの裏側にあるインフラや、Webアプリケーションの運用を支える仕事、今ではSREと呼ばれるような業務に携わってきました。 そして今年の1月から、さくらインターネットにてクラウドを中心にサービスの開発を行っています。つまり、インフラやクラウドを利用して一般のお客様向けにサービスを作るという仕事から、クラウドを作ることを仕事にする、という選択をしました。 この記事では、どのような経験からSREとして働くようになったのか、また現職に至る選択をした経緯について語りたいと思います。加えて、
こんにちわ。rwle1212です。本記事は JAWS Days 2020 で話す予定でしたが、昨今の事情によりオンライン開催となったため、登壇予定の内容を記事にしたものになります。 登壇していれば諸般の事情により左手首を骨折したネタが使えたのですが、ブログでは伝わらないので非常に残念な思いをしております。という話はどうでも良いので本題に入ります。 50分の登壇内容なので少々長くなりますが、お付き合いください。 JAWS Days 2019で登壇した内容の振り返り昨年の JAWS Days 2019 で「Infrastructure as Codeに疲れたので、僕たちが本来やりたかったことを整理する」という内容で登壇しました。 まずは上のリンクに添付されているスライドを5分位で読めると思うので一読頂いて、下の文に進んで頂ければと思います。 そもそもInfrastructure as Cod
OEM系→ODM系にシフトした背景ですが、1つは 価格競争力 です。 インフラにおいてプライスは重要な指標です。 また昔と今でヤフーのサーバーの買い方に違いがある事もポイントになっています。 昔のヤフーは、いろいろな部門が、いろいろな構成のサーバーを、いろいろなタイミングで購入していました。 この結果、納期面で有利なOEMを第一選択肢としていました。 またいろいろな構成のサーバーが入る事を考慮した結果、自営保守ではカバーしきれない範囲も多く、ベンダーが提供するサポートに依存している部分もありました。 しかし最近では 自社クラウド環境の普及により、決まった部門決まった構成決まったタイミングで購入するように になってきたため、 納期に関して余裕を持ったスケジューリングができるようになりました。 またクラウド環境で利用できるサーバーはかなりハイスペックなため、価格の数％の違いも大きなビジネスイン
「あけおめLINE」の負荷に耐えるインフラを作った話。LINEのインフラ設計を中の人に聞いた 国内外で展開する膨大なメッセージを処理する、LINEアプリのインフラってどうなっているの？ こんな素朴な質問をサーバー、ネットワークなど、中の人に聞いてみました。 2011年6月のリリース以来、右肩上がりの成長を続けるコミュニケーションアプリ「LINE」。主要4カ国（日本・タイ・台湾・インドネシア）の月間アクティブユーザー数は1億6,400万人を超えており、多くの人々にとって必要不可欠な社会的インフラにも等しいアプリになっています。 そして、多数のユーザーを抱えるアプリでは、膨大な量のトラフィックやデータを前提としてインフラアーキテクチャを設計する必要があり、インフラエンジニアの技術力がアプリの使い勝手に大きな影響を与えます。本稿では、LINE株式会社のサーバーサイドエンジニア 中村俊介さん、サ
監訳者のmizzyさんからご連絡いただき、出版社の方からご献本いただきました。いつもありがとうございます！ 原著、ずっと読みたいと思っていたところにすごく良いタイミングでの訳書出版で大変ありがたいです。 Infrastructure as Code ―クラウドにおけるサーバ管理の原則とプラクティス 作者: Kief Morris,宮下剛輔,長尾高弘出版社/メーカー: オライリージャパン発売日: 2017/03/18メディア: 単行本（ソフトカバー）この商品を含むブログ (2件) を見る ここ数年、Infrastructure as Code や DevOps といったコンテキストで様々ツールが登場し、注目され、多くの現場で活用されているとは思いますが、まだまだ成熟しきっていない分野でかつ比較的トレンドやツールが移り変わりの激しいフェーズで、ツールで語られることも多い中、本書ではツールの使い
サービスが生まれてから死ぬまで @激突！Aiming x CloverLab [インフラ対決]部門
2015/07/10 Infrastructure as Code Casual 札幌 #0 発表資料 http://infracode-sapporo.connpass.com/event/16476/
dots. Conference Spring 2016ゲーム開発の裏側 http://eventdots.jp/event/580344
この文章は、サーバサイドのウェブアプリケーション開発において、社内実績の少ない新しい言語を採用したときにインフラ面で考慮したことを社内向けにまとめたものです。はてなでは、長らくPerlでウェブアプリケーション開発を続けてきた一方、ここ数年で社内でScalaまたはGoの採用事例も増えてきました。 今後開発が始まるプロダクトにおいても、Perl、Scala、Goもしくは他の言語を採用するかどうかを開発開始時に選ぶことになるでしょう。 新言語を採用するときに、考慮すべきことの一つとして、「インフラ」への影響があります。 新言語に関する雑談をしていると、ウェブアプリケーションエンジニアに「インフラ」への影響について聞かれます。 もしくは、ウェブオペレーションエンジニアから考慮するポイントを伝えることもあります。ScalaやGo以外に、Node.jsやサーバサイドSwiftはどうかというのも雑談
秒間5万リクエストを処理する リアルタイム広告システム / BS3-3 新しい潮流：ビッグデータのリアルタイム応用：ユーザ事例 #QConTokyo
私はここ１週間ほど、同僚の 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と紹介されていたなとか頭
前編（「ビッグデータは"リアルタイム"でこそ価値がある」）では、リアルタイムなビッグデータ解析プロジェクト「CET（Capture EveryThing）」が始まったきっかけから、いまのチームまで組織に焦点を当てました。 後編では、いよいよビッグデータ解析のシステムについて深掘りしていきます。Amazonのクラウドサービスを活用して作り上げた現状のシステムを捨て、Googleで作る構成に変えようとしているそう。その意図とは。 クラウドサービスのコストパフォーマンスなど、エンジニアやアーキテクトには気になる情報が満載です。 「CET」で基盤構築や分析・集計アプリケーションの開発を行っている、吉田啓二さんに聞きました。 聞き手／構成／編集／写真：小川楓太（NEWPEACE Inc.）AWSで本格的に運用するのは厳しいかなという印象です —— 今回構築された基盤の具体的なシステム構成はどのよ
我々はどのように冗長化を失敗したのか
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
