サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
2023年03月31日追記：この記事を基に、@sadnessOjisanさんより、コードレベルにより踏み込んだ、かつ、グリーンスレッドベースの新しいWebサーバアーキテクチャも含めて整理された記事 Webサーバーアーキテクチャ進化論2023 |blog.ojisan.io が公開されました。 主に新卒のWebエンジニア向けに、古典的なWebサーバアーキテクチャを学ぶ道のりと代表的な実装モデルの概要を紹介します。 この辺りの話題がWeb界隈で流行っていたのは数年以上前というイメージですが、Webサービスは相変わらずWebサーバの上で動いているので、流行り廃り関係なく学ぶべき内容だと思っています。 また、HTTP/2がいよいよRFC化し、既にh2oやtrusterdなどのHTTP/2のサーバ実装があり、今後Webサーバアーキテクチャを再訪することが増えるような気がしています。 ところが、We
インフラ部の荒井（@ryot_a_rai）です。この記事ではクックパッドで利用しているプロビジョニングツール "Itamae" の紹介と細々した Tips を紹介します。 式年遷宮とプロビジョニングツール 現在、弊社ではインフラの式年遷宮*1を進めています。式年遷宮以前、弊社では Puppet を利用してサーバをセットアップしていましたが、式年遷宮に際して既存のプロビジョニングに関するコードは捨てることになるため、プロビジョニングツールの再検討を行うことになりました。 Puppet, Chef, Ansible, SaltStack を検討した結果、 言語特性の観点では、Ruby DSL な Chef が良い アーキテクチャ・エコシステムの観点では、シンプルな Ansible が良い といった点から、どれも決め手に欠ける状況で、Ruby DSL で記述できるシンプルなプロビジョニングツール
初めまして、インフラストラクチャー部の加藤 (@EugeneK) です。クックパッドでは現在178万ものレシピが公開されていますが、目的のレシピを探すために検索機能を提供しています。 今回は検索機能の裏側の仕組みについて、インフラストラクチャーの観点からお話ししようと思います。 全ての検索機能を支えるSolrと周辺のアーキテクチャクックパッドにはレシピの検索だけでなく様々な検索機能がありますが、その全てはSolrを活用して実装されています。 以前はMySQL Tritonnによる全文検索機能を使用していましたが、2011年頃からSolrに切り替わりました。クックパッドではSolrをマスタ - スレーブ構成にすることで冗長性と負荷分散を実現しています。以下の構成図をご覧ください。 マスタとスレーブの間には、リピータと呼ばれる検索インデックスを中継するためだけの役割のサーバがいます。この
JavaScript: Past, Present, and Future - NDC Porto 2020
20年越しの大規模リニューアルが進行中。「わくわく時間100%」を目指すDMM通販モダナイズプロジェクトの全貌
pixivが運用しているBOOTHの構成などについて
先日@naoya_itoさんが自身のブログ(インフラの継続的デリバリー)でKAIZEN platform Inc.のインフラについて書いていたやつの続編的な内容。 TL;DR Chat(Slack) + Hubot +CircleCI +GitHub を用いてセキュリティアップデートを自動化したGitHubのPull Requestを契機にセキュリティアップデートを実行できるようにしたCircleCIが大変便利。インフラ系の作業を自動化するのに非常に合っている気がする 背景 KAIZEN platform Inc.では、 ネットワーク脆弱性スキャン アプリケーション脆弱性スキャンセキュリティアップデートの定期実行 の3つをセキュリティ系タスクとして継続的にやっていこうという話になり、今回は私が担当した、「セキュリティアップデートの定期実行」の話。 RHEL系OSにはyumの自動更
弊社の夏期インターンシップpixiv SUMMER BOOT CAMP -2014-でインフラチーム代表ということでインターン生向けの講義をしました。普段は、全体のチーム説明しかしないんですが、今回はid:catatsuyの強い要望で、技術者向け講義が実現しました。がんばってスライドつくったのでとりあえず公開しておく。 5人くらいインターンに来てて、Webサービス運営してる人も3人くらい居たはずだけど、top叩いたことある人が2人とかで驚いた。趣味WebサービスだとPaaSが一般化していて、あんまりLinuxとか興味なさそうなかんじだ。自分が最初にLinuxを始めたときは自宅サーバと独自ドメインが流行りだしたころで、押し入れにおいたRed HatLinuxを載せたPCに、BINDと、Apacheと……ってセットアップしてPHPアプリケーションを動かしてたんだけど、いまはどうやって物理サー
AWS アカウントを複数人で使ってシステムを作っていく時に、セキュリティの面からやるべきことについて。 主に Web アプリケーションを想定した内容ですが、特に書いてあることは特殊ではないと思います。 各所のBlog にも記事書かれてますが思っていることをつらつらと書いてみます。 なんか変なこと言ってたらご指摘ください。 参考:AWSのセキュリティが気になるなら読んでおくべきAWSセキュリティのベストプラクティス - yoshidashingo はじめに (AWS アカウントと IAM ユーザ) 前提というか用語の話。AWS アカウント アカウント作成時のメールアドレス、パスワードでログインして使うユーザ IAM ユーザAWS アカウントから発行できる、ユーザ名とパスワードでログインして使うユーザAWS アカウント周りAWS アカウント (ルートユーザ) で作業できないように
「全体のリソース効率を上げましょう」というためのものである。 Reverse Proxy がなぜ必要か - naoyaのはてなダイアリー これは完璧に正しくて、ただ「リソース効率」という概念はあまり具体的な想像が追い付かない人がいそうだなと思ったので、ちょっとだけ補足しようと思った。 Reverse Proxyを入れることでリソース効率の向上を狙うんだけど、それは以下のような複数の場面におけるそれぞれのリソース効率向上を複合的に狙うものだ。 通常時のトラフィック配信におけるCPU・メモリ使用率を最適化する バースト時(過負荷時)のトラフィックをより細かく制御可能とする 障害時におけるダウンタイムおよび総合的な計算・配信能力の低下を極小化する 多数のサーバによる構成全体を増強・入れ替え・移動あるいは削減する際の自由度の向上を狙う 簡単にコンピュータの性能だけで言うと最初の項目だけをリソース効
フロントエンジニアに知ってもらいたいリバースプロキシの重要性 | RickyNews この記事が目に入って読んでみた。なるほど、昨今は Reverse Proxy は便利な L7ルーター的なものとして認識されているのだな、と思った。URL の Rewrite や、VirtualHost 云々。確かに Reverse Proxy の便利な側面ではある一方、それらはNginx などの Reverse Proxy でなければ実装が不可能かと言えばそんなことはないものでもある。 自分は Reverse Proxy はもうすこしサーバー/インフラ的な側面でその役割を捉えている。今更何をというものでもあるが、昼休みがてら時間があるので簡単に書いてみよう。 Reverse Proxy はWebシステム全体のリソース最適化のためのパーツ Reverse Proxy のインフラ的な視点での役割は「Web
前回 RAID に関するちょっとした話を書きましたが個人が巨大なストレージを運用するにあたって得られたノウハウをだいたい全部書いておきます。 そもそもメリットあるのか？ メリットはあります。金です。Google Drive は安いですが、それでも 1TB 月 1000 円です。しかし運用にかなり制限がでます。柔軟に使えるAmazon Web Service ならその 3 倍+転送量課金です。 16TB だと月 5 万円もかかってしまいます。ちなみにもっとも柔軟に使える EBS だと 16TB で 83000 円ぐらいです。Google Compute Engine の低冗長性ストレージは S3 より少し安かった気はするけど別にとても安いわけではなかったと思う(よく覚えていないし調べるのがめんどくさい)。 50TB のストレージをGoogle Drive でごまかしごまかし運用したと
他のホストのDockerコンテナには接続しづらい 1つのホストの上で複数のDockerコンテナを動かす場合、あるコンテナからあるコンテナに接続するためにはコンテナに付けた名前が利用できる。具体的には、コンテナの名前をもとにDockerが環境変数を提供してくれて、そこにアドレスとポート番号が入っている。しかし、複数のホストの上で複数のDockerコンテナを動かす場合、他のホストで動作しているコンテナに接続したいのであればこの方法は利用できない。単純に接続先のホストのアドレスとポート番号をコンテナ起動時に指定する方法もあるが、この方法では他のホストに接続する全てのコンテナに対して逐一指定する必要がある。ホストごとにリバースプロキシを置く 他のホストのコンテナへ接続するためのリバースプロキシとなるコンテナを各ホストごとに設置する。これにより、他のホストのコンテナに接続したい場合でも、あたかもコ
20年越しの大規模リニューアルが進行中。「わくわく時間100%」を目指すDMM通販モダナイズプロジェクトの全貌
データベースが落ち着いているので、その間に別のことに着手。 チームの監視システムがmonっつー超レガシーシステム。知っている人もいるかもしれないが、monはperl製のシンプルな監視システム。古くからあるものなんだけど「monperl」で検索すると「もしかして: manperl」とgoogle様にも何だっけソレ？と言われてしまうかわいそうな奴(「mon monitoring tool」だとちゃんと出てくる)。なのでまあこの際だから俺が葬り去ってやる。導入したSensuのバージョンは0.12.6。GW前くらいから運用しているが今んとこ問題ない。まだ運用期間短いね。 割と長文になっちまったので、目次をば。 0. sensu概要 1. なぜsensu？ 2. インストール 3. コンフィグの配置 4. プラグインについて 5.API 6. デバッグ 7. 今後の展望 0. sensu概要
こんにちは。今回はITサービスセンターより、インフラ運営の観点から急増するLINEインフラの課題と対応について記させていただきます。 はじめに 先日開催したLINE Developer Conference（インフラ編）には大勢の方にいらしていただきました。カンファレンスでは、LINEサービスが始まってから約2年の間に我々はどういった方法でインフラ運営を行い、またどんなことに悩んできたのかを、システム、データベース、ネットワークの観点からそれぞれ発表させていただきました。 カンファレンスはLINE株式会社が様々な技術をどのように使い、どのように運用を行っているのか。現在どのような技術的なことに取り組んでいるのか日本のエンジニアの皆さんに知っていただくために開催されました。結果としてインフラ編では150名の定員に対して430名のご応募をいただいたとのことでLINEサービスに対する関心の高さを
日々の出来事、メンバーの働く様子や声、未来への想いなど、Supershipの“BE SUPER”なストーリーをシェアしています。
こんにちは、運用部 アプリ運用グループの清水です。Golang鋭意勉強中です。 今回は、SNS「mixi」に限った話ではなく、ミクシィ社全体として利用している仮想環境について紹介したいと思います。パブリッククラウドも一部のサービスで利用していますが、今回は、自社で運用している仮想環境にフォーカスして書いてみようと思います。 今まで利用してきた仮想環境 今まで利用してきた仮想環境というと、手作業で構築したKVM（Kernel-based VirtualMachine）環境が中心でした。手作業といってもある程度手軽に構築できるように、シェルスクリプトとCobblerでVMを構築できるようになっています。構築の流れは以下のとおりです。 CobblerにVMのIPやホスト名などをスクリプトで登録する。 KVMのホスト上でスクリプトを実行（koanコマンドでCobblerと連携してVMをセットアッ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
