メルカリにおける、継続的なアプリケーション改善を支える技術 - Retty Tech Cafe #5 2016/03/12
![メルカリにおける、継続的なアプリケーション改善を支える技術 #retty_tech_cafe // Speaker Deck](https://cdn-ak-scissors.b.st-hatena.com/image/square/b2c4885b4c9b28e54d0e23d17b3a06d9f56e7647/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F0216964adda14fd99596291e3461a6f9%2Fslide_0.jpg%3F5990405)
この文章は、サーバサイドのウェブアプリケーション開発において、社内実績の少ない新しい言語を採用したときにインフラ面で考慮したことを社内向けにまとめたものです。 はてなでは、長らくPerlでウェブアプリケーション開発を続けてきた一方、ここ数年で社内でScalaまたはGoの採用事例も増えてきました。 今後開発が始まるプロダクトにおいても、Perl、Scala、Goもしくは他の言語を採用するかどうかを開発開始時に選ぶことになるでしょう。 新言語を採用するときに、考慮すべきことの一つとして、「インフラ」への影響があります。 新言語に関する雑談をしていると、ウェブアプリケーションエンジニアに「インフラ」への影響について聞かれます。 もしくは、ウェブオペレーションエンジニアから考慮するポイントを伝えることもあります。 ScalaやGo以外に、Node.jsやサーバサイドSwiftはどうかというのも雑談
The Twelve-Factor AppはHerokuが提唱しているマニフェスト的なもので、モダンなウェブアプリをつくる際に留意すべきポイントがまとまっています。意図するところがすぐにはわかりづらい表現がいくつかありますが、それに対して、Will Koffelがブログで "12-Factor Apps in Plain English" と題して、平易な言葉で解説してくれています。 I. Codebase — One codebase tracked in revision control, many deploys コードベースはソース管理システムに置き、多くの環境にデプロイできるようにしておくこと。。 II. Dependencies — Explicitly declare and isolate dependencies 依存するライブラリは明確に宣言し、コードをデプロイするとき
Introduction In the modern era, software is commonly delivered as a service: called web apps, or software-as-a-service. The twelve-factor app is a methodology for building software-as-a-service apps that: Use declarative formats for setup automation, to minimize time and cost for new developers joining the project; Have a clean contract with the underlying operating system, offering maximum portab
皆さんは、The Tweleve-Factor Appをご存知だろうか? これはHerokuの中の人が書いた、Webアプリケーションを使いやすい形でスケーラブルにするための方法論である。簡単にいえばコンテナで動かしたいアプリケーションが守っておくとよいレシピ集であると言える。 http://12factor.net/ (日本語訳) 今回これを取り上げた背景としては、実はDockerコンテナをメインにした本番でのインフラ運用を考えた時に、アプリケーションがこの12の要素を満たしていることが重要だと最近ひしひし感じているから。 実際、自分が働いているところが運営しているサービス Wantedlyは、もともとずっとHerokuで運営していて、最近AWSに移行し、現在Dockerコンテナの上で動いている。この移行を約1ヶ月半で実現できた大きな要因として、Herokuの上に乗っていたことで知らず知ら
この記事ははてなエンジニアアドベントカレンダー2015の1日目です。今回は、既存の運用フローに乗せやすいDockerイメージへのchrootによるデプロイの考え方と自作のコンセプトツール droot を紹介します。 github.com 背景 Docker 本番導入の課題 Docker 導入の目的 Docker + chroot のアイデア droot: Dockerイメージにchrootするコンテナツール droot の使い方 droot push: Dockerイメージをtar ball化しS3にpushする droot pull: S3にpushしたイメージをダウンロードし展開する droot run: 展開先のディレクトリにchrootする droot の実装 droot push/pull の実装 droot run の実装 あわせて読みたい あとがき 背景 Dockerがリリー
AWSのリソース構成をServerspecのようにテストできる "awspec" をつくりました。 github.com 例えばEC2インスタンスであれば、以下のように書けます。 describe ec2('my-ec2') do it { should exist } it { should be_running } it { should_not be_stopped } its(:instance_id) { should eq 'i-ec12345a' } its(:private_ip_address) { should eq '10.0.1.1' } it { should have_security_group('my-security-group-name') } it { should belong_to_vpc('my-vpc') } it { should belon
July Tech Festaで発表した資料です。 Cloud Foundry、OpenShift v3、Deis、Flynnを取り上げて、Open PaaSの今と未来について解説しました。Read less
はじめに はじめまして。クックパッド株式会社の荒井(@ryot_a_rai)と申します。 今回から全5回、構成管理ツールであるItamaeの入門から実際の活用例までを解説していきます。今まで構成管理ツールを使ったことがなかった方から、Itamaeをすでに使っている方まで、ぜひご覧ください。 Itamaeとは Itamaeは筆者が中心となって開発を進めているオープンソースの構成管理ツールです。同様のツールとしてはPuppet、Chef、Ansibleなどが有名ですが、ItamaeはChefに影響を受けています。Chefの記述性・柔軟性を持ちながら、シンプルで導入しやすい構成管理ツールを目指して開発が進んでいます。 構成管理ツールの必要性 Itamaeの解説を始める前に、構成管理ツールを使う理由について軽く考えてみたいと思います。 サーバ構築の自動化 手動構築の手間と時間を減らす 手動構築によ
中〜大規模サービスのインフラの様子を知りたいアプリケーションエンジニア向けに、もともとアプリケーションコードを書いていた視点から、個人的な体験をベースにはてなで大規模サービスのインフラを学んだ過程や学んだ内容の一部を紹介します。 Webアプリケーションのブラックボックス Webアプリケーションフレームワークの向こう側 なぜ複数のサーバが必要なのか 突然のWebサービス3層構成 リバースプロキシ アプリケーション データベース その他のコンポーネント キャッシュは麻薬 飛び道具としてのKVS/NoSQL 非同期処理 バッチ処理 Mackerelの場合 参考 まとめ Webアプリケーションのブラックボックス 今年もはてなインターンの時期が近づいてきた。 毎年ではないけど、はてなインターンでは「インフラ講義」というのをやっている。 今年はインフラ講義の講師としてアサインされたのでちょうど何を話そ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く