O'Reilly Velocity Conference 2018 San Jose参加レポート - インフラエンジニアway - Powered by HEARTBEATS
こんにちは、ハートビーツの滝澤です。 2018年6月12日〜14日にサンノゼで開催されたO'Reilly Velocity Conference 2018 San Joseに参加してきました。 弊社ではここ数年は毎年この時期に開催されるVelocity Conferenceに参加しており、今年は弊社の與島と阿部と一緒に参加してきました。 Velocity Conferenceは主に運用やDevOps向けのイベントになります。 本記事では興味深かったセッションをいくつか紹介します。 なお、内容については紹介している資料を確認してください。聞き間違えたり、認識が違っているかもしれないためです。 Kubernetes Canary deploys with Kubernetes and Istio 資料: Canary deploys with Kubernetes and Istio (PDF
「本番環境などという場所はない」マイクロソフトがSaaSの失敗と成功から学んだ、アジャイルからDevOpsへの進化（後編）。Regional SCRUM GATHERING Tokyo 2016
「本番環境などという場所はない」マイクロソフトがSaaSの失敗と成功から学んだ、アジャイルからDevOpsへの進化（後編）。Regional SCRUM GATHERING Tokyo 2016 アジャイル開発手法の1つであるスクラムをテーマにしたイベント「Regional SCRUM GATHERING Tokyo 2016」が1月19日と20日の2日間、都内で開催されました。 そこでマイクロソフトが行ったセッション「マイクロソフトが実践したScrum導入7年間の旅。そしてDevOpsへの進化」は、アジャイル開発からクラウドサービスの提供へと進んだマイクロソフトが、サービス開発の過程で学んださまざまな知見を共有するものとなりました。 （本記事は「「本番環境などという場所はない」マイクロソフトがSaaSの失敗と成功から学んだ、アジャイルからDevOpsへの進化（前編）。Regional S
運用エンジニアから開発エンジニアになるためにやったこと · As a Futurist...
Web の会社でエンジニアを始めて 4 年、ずっと運用エンジニアをやってました。運用とは端的に言うと、社内外の他人が作ったソフトウェアを期待通りに動作させるためのエンジニアリングだと思ってます。アプリケーションはもちろん開発者が作ったものですし、MySQL や Apache や Linux も全部他人が作り上げたソフトウェアであり、それらの設定を変更したりパッチを当てたり運用ツールを駆使することで、協調動作させることに磨きをかけてきました。 ただ、いつまでたっても他人の作ったものの面倒を見てることには変わりないし、運用ツールを開発したところでそれはあくまで誰かが生み出す価値のサポートにすぎないのが自分的には満足できなくて、ずっとアプリケーション(ビジネスロジック)が作りたいと思ってました。 で、今年の始めからたまたまタイミングよく新規開発の部署に入ることになって、いきなり開発者をやることに
僕がホスティングサービスで学び考え、取り組んだこと。 | Pocketstudio.jp log3
踊るホスティティングサービス 変化を強いられる時代 壁を越え、進む あの日僕が BASIC に挫折した事を忘れない オープンソースを積極活用、そして一次対応へ 閾値主義からの脱却 一次対応の闇 一度は仕事を辞める覚悟をした 正直、もう人間が運用や監視対応するのは限界かもしれない Serf the Librator ――運用対応自動化が、進化への鍵か 今日よりも鮮やかに 概要と書きたかったこと 師走です。年の瀬ですね。寒くなりましたね。コタツが恋しいです。ミカンおいしいです(^q^) そんな季節柄、ふと、自分の仕事を振り返りたくなりました。 僕はこれまで、ホスティングサービスの中の人として歩んできました。自分が何を考え、どのように行動を起こしてきたか。その経緯は、今の自分しか書けない気がして。色々なスライドや twitter では伝えきれなかった事を、一度まとめたいなぁと。なので、こうやって
MySQLをmaster:slave=1:1構成にして参照をslaveに向けるのがなぜ良くないか - 酒日記 はてな支店
MySQLのmasterとslave 1:1にして参照をslave向けるのってやりたがる人多いみたいだけど、性能たいして上がらない割に可用性落ちるだけだからやめようキャンペーン 2011-06-19 00:16:30 via YoruFukurou MySQL はレプリケーションが簡単に構成できるのですが、時折 master 1台 に対して slave 1台、更新処理は master に、参照は slave に、という構成を目にします。 個人的にはこの構成はお勧めでないと思っているので、その理由を考察してみます。 1. 可用性が落ちる 当然ですが、master, slave のどちらが落ちても影響を受けるために可用性が低下します。 2. 全体の性能がほとんど上がらない master 1台ですべてのクエリを処理する場合と比べて、可用性が落ちる引き換えとして見合った性能向上が得られるか、という
データベースのmasterとslaveの使い分けの話。2014年版 - Hateburo: kazeburo hatenablog
社内で少し話題になったので。 運用上の話はfujiwaraさんの MySQLをmaster:slave=1:1構成にして参照をslaveに向けるのがなぜ良くないか - 酒日記 はてな支店 MySQLで参照の負荷分散を行うslaveは3台から構成するのがよいのでは - 酒日記 はてな支店 をみてください。 最近、新しくサービスができたり、新規機能でデータベースを追加する際には必ず全ての参照をmasterに向けてもらっています。理由は上記のエントリを読んでください。このような構成が取れるのはもちろん性能的にそれで問題ないからです。 新しいハードウェアに、設定されたMySQL、問題のないように書かれたSQLであれば、数千QPSは余裕に、また少し頑張れば数万QPSを一台で賄えます。なので大体のサービスはmaster一台で十分です。 さらにこの考え方を進めて、Webアプリケーションの中で sub d
Plack時代のReverse proxyによるサーバー運用方法 ~YAPC::Asia2010の復習(後編)~ | hirobanex.net
後編を書く前に、YAPC::Asia2011が終わってしまったので、変な勘違いをされるかとやめようかと思ったのですが。。。とりあえず、YAPC::Asia2010の復習として、Plack時代のPerlによるサーバ運用では、わりと一般的なリバースプロクシによる運用を、このブログの実例で報告します。 前置き:plackupはわかったけど、実際どうするの? 「Perlは遅い」の原点だったApacheのcgi時代は終わりを告げ、Apacheに依存したmod_perl時代も終りを告げました。Plackを使えば、CGIだろうとmode_perlだろうとPerlのスタンドアローンサーバーであろうと、かなり汎用的に動かせる時代です。mod_perlとかFastCGI前から使っていれば、あるいは、「Rubyではふんふん、Pythonではふんふん」とか語れれば、いろいろな歴史をしっているからすぐ実践しやすいと
nohupコマンドの実行パターン。 - こせきの技術日記
実行に時間がかかるコマンドはnohupで実行する。 nohup ${時間がかかるコマンド} > /tmp/nohup-$(date +"%Y%m%d%H%M%S").out 2>&1 < /dev/null &標準出力がリダイレクトされていない場合は、./nohup.out か $HOME/nohup.out に出力される。 SSH接続時は標準入力を閉じる必要がある。 ログアウトしてもバックグラウンド ジョブを継続する方法 SSH + nohup でバックグラウンドプロセスを実行してログアウトするときの注意点 - takihiro日記 技術/UNIX/なぜnohupをバックグランドジョブとして起動するのが定番なのか？(擬似端末, Pseudo Terminal, SIGHUP他) - Glamenv-Septzen.net
ヤフーネットワーク10年
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog はじめに こんにちは、ヤフーでネットワーク設計に携わって早10年の松谷と申します。 今回はヤフーネットワーク10年と題し、ヤフーの重要配信インフラの一部であるネットワークについて、過去の課題と共にご紹介していきたいと思います。 2000年 この頃のヤフーでは検索やオークションといったサービスのウェブサーバーへ、大量のアクセスが集中し高負荷になる事が多々ありました。当時、ほとんどのサービスが皆さんご存じのDNS Round Robin（以下DNSRR）で運用していました。DNSRRは非常にシンプルで優れた機能ですが、サーバー障害時にはAレコードを手動で抜く作業が必要です。またDNSの512byte問題でAレコードを束ねるのが限界にな
この一年のブログエントリまとめ - blog.nomadscafe.jp
こうやって並べてみると、転職したことで課題ががらりと変わったのがわかるような気がする今年のエントリまとめ。 1月に書いた2つのエントリー。mixiアプリのバックエンドで大変だったころ。 データベースサーバを複数台構成とか2010年代には流行らない アプリケーションがマルチスレッドでもマルチコアCPUを活かせない件 んで、5月にミクシィ退社。退職しましたエントリニーにブクマいっぱい。これがブクマ数一番多いとかじゃなくてよかった。 株式会社ミクシィを退職しました 退職直前まで作っていたリソース監視ツールをオープンソースにて公開。転職後のライブドアにてさらにブラッシュアップしていく事になります。 CloudForecastっていうリソース監視のツール／フレームワーク作った 6月にライブドアにJOIN。もうちょっと有休消化すればよかったなといまさら反省。 株式会社ライブドアに入社しました 入社後に
これがWikipediaの裏側、知られざる大規模システムの実態「Wikipedia / MediaWiki におけるシステム運用」
Wikipediaといえば世界で第5位の訪問者数を誇る巨大サイトですが、システム運営に携わる人間は世界でわずか6人、しかもこれはボランティア込みという恐るべき少人数で、第4位のFacebookのサーバ数が3万台を超えているのに対して、Wikipediaはわずか350台で運用している……などというような感じで、知られざる今のWikipediaの実態が「KOF2010」にて本日行われた講演「Wikipedia / MediaWiki におけるシステム運用」で明かされました。 登壇したのはWikipediaを運営するWikimedia財団のエンジニアであるRyan Lane氏で、100席ある座席は満席になり、隣の中継の部屋まで人があふれているほどの盛況っぷりで、語られる内容もなかなか参考になることが多く、今後のGIGAZINEサーバにも活かせそうな内容でした。 というわけで、「Wikipedia
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
人間は誰でもミスをする、システムは必ず障害を起こす──トラブルを減らす“6つの知恵”
http://blog.quall.net/linuxserver/182/
とあるアプリの開発運用(トラブルシュート)