Cybozu Meetup #6 大規模サービスを支える名脇役たちでの発表 https://cybozu.connpass.com/event/61329/
VISAカードのインフラがDocker採用。数秒でプロビジョニング、パッチやメンテにさよなら、消えるインフラ。DockerCon 2017 4月に米テキサス州オースチンで開催されたDockerのイベント「DockerCon 2017」では、コンテナランタイムのためのLinuxコンポーネント「LinuxKit」の発表や、コンテナランタイムを組み立てる「Moby Project」の発表など、同社の新しい方向性を示す発表が相次いで行われました。 そのなかでもう1つ、DockerCon 2017ではグローバルな決済サービスを提供しているVisaが、同社のインフラにDockerを採用したという事例が発表されました。これまでDockerは開発環境やテスト環境への採用が進んでいましたが、Visaのような著名な企業が本番環境でDockerを採用した事例の発表は、Dockerの本番環境への導入を市場に説得す
インフラエンジニアも、そうでないエンジニアも、程度の差こそあれAWS(パブリッククラウド)の知識は欠かせないものになりつつあります。しかしながら、食わず嫌いだけならまだしも、AWSにそこそこ取り組み続けているのに、しばしば嫌気がさすことすらあるのは、AWSの複雑さが原因の1つであるといっていいでしょう。 今回は、そんな複雑な仕組みの一つを、Terraform用にコード化することでココロのスキマ、お埋めします。 Infrastructure as Code の過程 Infrastructure as Code によって、手動管理をやめて自動化することのメリットは言うまでもないですが、今回は自動化する過程にこそ非常に大きなメリットがある、という視点にスポットを当てていきます。 AWSは多機能で便利であるがゆえに、複雑です。そして、複雑であるがゆえに、お客さんに簡単に扱ってもらえるよう、操作が簡
↑2016年のよく使われるDevOpsツール。Docker、Ansibleが伸びています。 (RightScale: New DevOps Trends: 2016 State of the Cloud Surveyより) こんにちは、吉岡(@yoshiokatsuneo)です。 ウェブサービスを作るにはどうしたらいいでしょうか? 当然ですが、プログラムを書く必要があります。Ruby on Rails、MEANスタック、LAMP、などフレームワークを選択した後は その方法論に従ってコードを書いていきます。 開発はローカルのパソコンで行いますので、サーバ・ネットワークなどインフラについて考える必要はありません。 しかし、実際にサービスをリリースして使ってもらうには、そのサービスをサーバで動かす必要があります。 サービスを安定して継続的に動作させるにはインフラの知識が不可欠です。 従来、ハード
この文章は、サーバサイドのウェブアプリケーション開発において、社内実績の少ない新しい言語を採用したときにインフラ面で考慮したことを社内向けにまとめたものです。 はてなでは、長らくPerlでウェブアプリケーション開発を続けてきた一方、ここ数年で社内でScalaまたはGoの採用事例も増えてきました。 今後開発が始まるプロダクトにおいても、Perl、Scala、Goもしくは他の言語を採用するかどうかを開発開始時に選ぶことになるでしょう。 新言語を採用するときに、考慮すべきことの一つとして、「インフラ」への影響があります。 新言語に関する雑談をしていると、ウェブアプリケーションエンジニアに「インフラ」への影響について聞かれます。 もしくは、ウェブオペレーションエンジニアから考慮するポイントを伝えることもあります。 ScalaやGo以外に、Node.jsやサーバサイドSwiftはどうかというのも雑談
主にアプリケーション開発者向けに、Linuxサーバ上の問題を調査するために、ウェブオペレーションエンジニアとして日常的にやっていることを紹介します。 とりあえず調べたことを羅列しているのではなく、本当に自分が現場で使っているものだけに情報を絞っています。 普段使っているけれども、アプリケーション開発者向きではないものはあえて省いています。 MySQLやNginxなど、個別のミドルウェアに限定したノウハウについては書いていません。 ログインしたらまず確認すること 他にログインしている人がいるか確認(w) サーバの稼働時間の確認 (uptime) プロセスツリーをみる (ps) NICやIPアドレスの確認 (ip) ファイルシステムの確認(df) 負荷状況確認 top iostat netstat / ss ログ調査 /var/log/messages or /var/log/syslog /
分散システムについては、もう随分と前から学びたいと思っていました。ただ、それは一度首を突っ込んだら最後、ゴールのない迷路に迷い込むようなものなのです。どこまでも続いているウサギの穴のようなものです。分散システムに関する文献は星の数ほど存在します。様々な大学からたくさんの論文が発表されているばかりでなく、膨大な数の書籍もあるのです。私のような全くの初心者には、どの論文を読んだらいいのか、どの書籍を買ったらいいのか、見当もつきません。 そんなとき、一部のブロガーが、 分散システムエンジニア (それがどういう意味であれ)になるなら知っておくべき論文というものを推奨しているのを見つけました。その一部を紹介しましょう。 FLP , Zab , Time, Clocks and the Ordering of Events in a Distributed Systems , Viewstamped
監視を育てる、Mackerel クラウド時代に最適な監視モデルを使いやすいUIで提供し、システムの運用・監視にチームで取り組む文化を作る「クラウド運用の道標」となるSaaS型サーバー監視サービス。 特長 Mackerelが選ばれる理由 Mackerelは、株式会社はてなが提供する日本製のサーバー監視サービスです。自社のサービス運用基盤をMackerelで運用し、そのノウハウを詰め込むことで、クラウド監視に必要な機能を提供し続けています。 圧倒的に手軽な導入 サーバーに監視エージェントをインストールするだけで、すぐにサーバー監視を始められます。 詳しく見る 育てる監視 様々なコミュニケーションツールとの連携によりチームでの情報共有を促進し、システムの状態に合わせて監視を育てるきっかけを作ります。 詳しく見る 高度な監視 複数メトリックの組み合わせや将来の予測値の監視、機械学習を使って過去の傾
中〜大規模サービスのインフラの様子を知りたいアプリケーションエンジニア向けに、もともとアプリケーションコードを書いていた視点から、個人的な体験をベースにはてなで大規模サービスのインフラを学んだ過程や学んだ内容の一部を紹介します。 Webアプリケーションのブラックボックス Webアプリケーションフレームワークの向こう側 なぜ複数のサーバが必要なのか 突然のWebサービス3層構成 リバースプロキシ アプリケーション データベース その他のコンポーネント キャッシュは麻薬 飛び道具としてのKVS/NoSQL 非同期処理 バッチ処理 Mackerelの場合 参考 まとめ Webアプリケーションのブラックボックス 今年もはてなインターンの時期が近づいてきた。 毎年ではないけど、はてなインターンでは「インフラ講義」というのをやっている。 今年はインフラ講義の講師としてアサインされたのでちょうど何を話そ
インフラ部の荒井(@ryot_a_rai)です。この記事ではクックパッドで利用しているプロビジョニングツール "Itamae" の紹介と細々した Tips を紹介します。 式年遷宮とプロビジョニングツール 現在、弊社ではインフラの式年遷宮*1を進めています。式年遷宮以前、弊社では Puppet を利用してサーバをセットアップしていましたが、式年遷宮に際して既存のプロビジョニングに関するコードは捨てることになるため、プロビジョニングツールの再検討を行うことになりました。 Puppet, Chef, Ansible, SaltStack を検討した結果、 言語特性の観点では、Ruby DSL な Chef が良い アーキテクチャ・エコシステムの観点では、シンプルな Ansible が良い といった点から、どれも決め手に欠ける状況で、Ruby DSL で記述できるシンプルなプロビジョニングツール
CloudWatchがあればZabbixとできること大して変わらないし 「CloudWatchでだいたいの要件は満たせそうですね。」 とおっしゃる方もいらっしゃるようですが私たちServerworksが、そして私伊藤がなぜZabbixをおすすめするのか今回はそのことについてお話ししたいと思います。 統合監視ができる CloudWatchはあくまでもAWSの中の事象だけを見ます。 しかし実際のシステム運用ではAWSだけでなく他のクラウドシステムやオンプレミス、 クラウドとの接続ポイントとなるネットワーク機器など、監視すべき部分はAWSの中だけではありません。 そういった場合すべてを統合的に見られる監視ツールが必要となります。 またAWSの中だけであったとしてCloudWatchではアカウント毎に表示されることになります。 たとえば経費分割のために1つの会社で事業部毎に別々のAWSアカウントを
アーキテクトのItoです。動画を撮るのが趣味ですが、最近はこの本を買って、カラーグレーディングの勉強をしています。とても良い本です。 さて、今回お話するのはバックエンドにあるフロントエンドについて。 以下はほぼ実際にカメリオで運用しているバックエンド構成です。 図中のサーバーというものはいわゆるHTTPベースのサーバーアプリで、ここでは緑をNode.js, グレーをPython, C++で実装しています。小さいサーバーがたくさんあります。主にクライアント〜フロントエンドAPIだけの構成図で、記事クローラーや各種管理画面などは図にはありませんが存在します。 まずフロントエンドにELB(AWSを使用)とNginxを置き、後ろに NodeベースのフロントエンドAPIサーバーを置きます。 ここはNode.jsで作られたアプリをサービスするごく一般的な方法です。 エンドポイント(api.kamel.
フロントエンジニアに知ってもらいたいリバースプロキシの重要性 | RickyNews この記事が目に入って読んでみた。なるほど、昨今は Reverse Proxy は便利な L7 ルーター的なものとして認識されているのだな、と思った。URL の Rewrite や、VirtualHost 云々。確かに Reverse Proxy の便利な側面ではある一方、それらは Nginx などの Reverse Proxy でなければ実装が不可能かと言えばそんなことはないものでもある。 自分は Reverse Proxy はもうすこしサーバー/インフラ的な側面でその役割を捉えている。今更何をというものでもあるが、昼休みがてら時間があるので簡単に書いてみよう。 Reverse Proxy はWebシステム全体のリソース最適化のためのパーツ Reverse Proxy のインフラ的な視点での役割は「Web
Linuxの管理をしていると、OSが搭載されているハードウェア情報を取得する事がある。 今回は、そんなときに使えるハードウェア情報を取得するコマンドを紹介する。 1.lscpu CPUに関する情報を取得するコマンド。コア数やスレッド数、仮想に対応しているか否か等の情報を取得出来る。 以下に実行例を記載する。 $ lscpu Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 4 On-line CPU(s) list: 0-3 コアあたりのスレッド数:1 ソケットあたりのコア数:4 Socket(s): 1 NUMAノード: 1 ベンダーID: GenuineIntel CPUファミリー: 6 モデル: 23 ステッピング: 10 CPU MHz: 2833.596 Bo
データセンターやクラウドといったIT分野に身を置いているのであれば、コンテナという一般名称と、「Docker」というその具体的な製品名称を1年以上にわたって各所で見聞きしてきているはずだ。その話題性は、6月にリリースされたDockerのバージョン1.0でさらに高まっている。 こういった話題性の高まりは、企業が驚くべきペースでDockerを導入しているせいもある。筆者は7月に開催されたオープンソースカンファレンス「OSCON」に参加して、自社のサーバアプリを仮想マシン(VM)からコンテナに載せ替えている企業が数多くあるのを実感した。実際、Dockerのサービスおよびサポート担当バイスプレジデントのJames Turnbull氏は、同カンファレンスの場で筆者に対して、Dockerを試験的に導入していた最大手の銀行のうち3行が本番環境に移行したと語った。どのような技術であっても、バージョン1.0
2014年08月04日11:11 インフラ Ansibleを使って誰でも簡単安全にサーバ構築できる仕組みを作る Ansible って何なの? サーバに対してミドルウェアのインストールや設定等の環境構築を行うことをプロビジョニングと言いますが、その作業を自動化させるためのツールです。プロビジョニングを手動で行うと、手間も掛かるし、どうしてもミスが起こりえます。 その点、Ansible のようなツールを使えば、コマンド一発でプロビジョニングが走り、さらに冪等性(何度実行しても同じ結果になる)も確保されるため、誰でも簡単安全にサーバ構築が出来るのです。 同様のことを行うツールとして、Chef や Puppet がありますが、Ansible はそれらの中でもシンプルなことが特徴です。Chef は以前使ってみようと思い触ってみたのですが、覚えることが多かったりして挫折してしまった。。Ansible
ども、大瀧です。 Dockerコンテナをデプロイするツールが欲しいという理由でAWS OpsWorksとの組み合わせを以前のエントリーで紹介しましたが、今回は別のアプローチでデプロイを行うGearDを試してみました。 GearDとは GearDは、Red Hat社が開発するDockerコンテナを管理するCLIツール兼エージェントです。 最近、ITニュースサイトのPublickeyで紹介された、Project Atomicのコンポーネントの1つです。Project Atomic自体はRHELベースの軽量Linuxディストリビューション(Atomic Host)を前提とするものですが、GearDは独立した造りになっており、Fedora 20およびRHEL 7-Beta(EPEL経由なのでサポートなし)で動作します。 ブログ記事 : GearD: The Intersection of PaaS
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く