タグ

serverとnetworkに関するkasahiのブックマーク (10)

  • インフラエンジニアが学ぶと良さそうなgRPCサーバーについて - じゃあ、おうちで学べる

    3-shake にはSreake共有会 という毎週、火曜日と木曜日に担当者が現場で得た知見などを発表する社内勉強会が開催されています。こちらのブログはそれらを変更修正しております。 syu-m-5151.hatenablog.com 元々しようとしていたの話 Go 1.18 の最新情報←Generics の深い話とかはもう既出すぎて気になる人は読んでる Go でのTDD(が実は20周年なので)←書いてる途中で自分が言うべきことなんてないことに気付く 今後、案件で増えるであろう gRPC についてインフラエンジニアが知っておいても良いと思ったという話 ← 今ここ TL;DR protobuf (Protocol Buffers) はデータフォーマットで、JSONの役割を置き換えるものです。一方 gRPC は通信プロトコルで、HTTPの役割を置き換えるものです。 gRPC をライブラリやツール

    インフラエンジニアが学ぶと良さそうなgRPCサーバーについて - じゃあ、おうちで学べる
  • ネットワーク越しリトライ考 - その手の平は尻もつかめるさ

    ここ最近では何らかのインターネットサービスを構築・運用するにあたって、ネットワーク越しのリトライを考えることは避けられなくなりつつあります。 micro services のようなアーキテクチャを採用している場合はサービス間のメッセージのやり取りはまず失敗する前提 (つまりリトライをする前提) で組む必要がありますし、たくさんのクライアントがいてそのクライアントが定期的に何かを処理してセントラルにデータを送ってくる IoT のようなシステムを構築する時もその処理のリトライをよく考える必要があります。 というわけで「ネットワーク越しのリトライ」についてここ最近考えていることをざっくりと書き留めるものであります。 前提 リトライをする側をクライアント、リトライを試みられる側をサーバと呼称します リトライにおいて、サーバおよびネットワークはクライアントよりも弱者です クライアントはリトライをコン

    ネットワーク越しリトライ考 - その手の平は尻もつかめるさ
  • システム構成図をテキストで

    Gigazineさんでdrawthe.netを取り上げていたので紹介です。使い方はGigazineさんのほうが丁寧なので、気になる方はチェックしてみてください。(2020年12月1日、追記) drawthe.netとは cidrblock/drawthe.netは複雑なネットワーク図も「テキストで書いてブラウザ上でSVGレンダリングできるようにしよう」というコンセプトのもと開発されたツールです。下図のように複雑な構成図も精度高く描くことができます。 拡大してみると情報量が多いこと、またいかに整っているかがわかると思います。 デモサイトも用意されているので、サクッと試したい場合はコチラが便利です。コードはGitHubで公開されています。更新が2017年末で止まってしまっているのが玉に瑕ですが、十分な性能を発揮してくれます。 drawthe.netを使いたい理由 美しい構成図といえばInter

    システム構成図をテキストで
  • プログラマーが「ネットワーク怪しくない?」と思った時に覚えておくと便利なことまとめ - LIVESENSE ENGINEER BLOG

    インフラエンジニアの中西です。 最近プログラマーからこのような話を耳にします。 「ネットワークって難しい/よくわからない」 最近ではAWS,GCPをはじめとするクラウドサービスが充実しているのでWeb界隈のエンジニアはなおさら気にするシーンが少なくなったように思います。 今日は最低限これだけ覚えていたら有事の際にちょっとは役に立ちますよという話が出来たらなと思います。 書式統一のため sudo を省略しています。ご容赦下さい。 コマンド編 ping ping です。疎通確認を行う時のコマンドです。 さすがに分かると聞こえてきそうですね。 例えば、192.168.1.1 というサーバに通信を確認したい場合はこうです。 $ ping 192.168.1.1 繋がる場合はこうなります。 $ ping 192.168.1.1 PING 192.168.1.1 (192.168.1.1): 56 d

    プログラマーが「ネットワーク怪しくない?」と思った時に覚えておくと便利なことまとめ - LIVESENSE ENGINEER BLOG
  • Reverse Proxy がなぜ必要か - naoyaのはてなダイアリー

    フロントエンジニアに知ってもらいたいリバースプロキシの重要性 | RickyNews この記事が目に入って読んでみた。なるほど、昨今は Reverse Proxy は便利な L7 ルーター的なものとして認識されているのだな、と思った。URL の Rewrite や、VirtualHost 云々。確かに Reverse Proxy の便利な側面ではある一方、それらは Nginx などの Reverse Proxy でなければ実装が不可能かと言えばそんなことはないものでもある。 自分は Reverse Proxy はもうすこしサーバー/インフラ的な側面でその役割を捉えている。今更何をというものでもあるが、昼休みがてら時間があるので簡単に書いてみよう。 Reverse Proxy はWebシステム全体のリソース最適化のためのパーツ Reverse Proxy のインフラ的な視点での役割は「Web

    Reverse Proxy がなぜ必要か - naoyaのはてなダイアリー
  • ヤフーネットワーク10年

    ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog はじめに こんにちは、ヤフーでネットワーク設計に携わって早10年の松谷と申します。 今回はヤフーネットワーク10年と題し、ヤフーの重要配信インフラの一部であるネットワークについて、過去の課題と共にご紹介していきたいと思います。 2000年 この頃のヤフーでは検索やオークションといったサービスのウェブサーバーへ、大量のアクセスが集中し高負荷になる事が多々ありました。当時、ほとんどのサービスが皆さんご存じのDNS Round Robin(以下DNSRR)で運用していました。DNSRRは非常にシンプルで優れた機能ですが、サーバー障害時にはAレコードを手動で抜く作業が必要です。またDNSの512byte問題でAレコードを束ねるのが限界にな

    ヤフーネットワーク10年
  • 高負荷サイトのボトルネックを見つけるには : DSAS開発者の部屋

    はじめに アクセスが急増すると、応答時間が著しく悪化するサイトはありませんか? 普段は200ミリ秒以内で安定してアクセスをさばいているのに、イベントやらキャンペーンやらを開始した瞬間から、普段の2倍や3倍のアクセスが殺到し、その結果、レスポンスタイムが3秒とか9秒とかかかるようになってしまうことってありますよね。 あるサイトの実状 つい先日まで、そんなサイトが私の目の前にもありました。自社で運営している某ソーシャル系のサイトなんですが、イベント開始時刻と同時にアクセス数が急増するのです。とはいえ、所詮は普段の2倍とか3倍程度の数なのだから、少なくとも1秒以内にレスポンスを返せるくらいの性能は維持したいものです。 しかし実際は困ったことに、応答に3秒以上もかかってしまう処理が大量に発生してしまう状況に陥ってしまっていました。これはきっと、どこかにボトルネックがあるに違いありません。 仮説を立

    高負荷サイトのボトルネックを見つけるには : DSAS開発者の部屋
  • 小悪魔女子大生のサーバエンジニア日記

    ECC版SSL証明書インストール体験記その4 02.08.13 / 未分類 / Author: aico / Comments: (0) では、いよいよ発行されたECC証明書をインストールしましょう! 実はECC版SSL証明書は現在、ブラウザ・OSによっては対応していないものも多いので、 対応していないものはRSAの証明書を読むように、ECCとRSAのハイブリッド構成をすることが出来ます。 そしてなんと、ECCの証明書を申請するとRSAの証明書も一緒にもらうことが出来ます(ベリサインさん太っ腹!) なので今回はECCとRSAのハイブリッド構成を組みつつ証明書のインストールを行います! まずはベリサインのサイトで中間証明書を確認しましょう。 発行されたCRT、中間証明書、秘密鍵は必ず対になっている必要があります。 対になっていないとエラーになってしまいます。。 小悪魔ブログは最初、中間証明書

    kasahi
    kasahi 2010/07/26
    これはすばらしい
  • [Think IT] サーバが重いってどういうこと? (1/3)

    サーバが重いってどういうこと? 著者:ウノウ  尾藤 正人   2007/10/4 2007年10月の連載ランキング1位(一覧を見る) サーバ管理者だけではなく誰でも一度は経験したことがある「サーバが重い」という現象。一言で「重い」というのは簡単ですが、重いというのは具体的にどういうことなのでしょうか。 ここでいう重い・軽いは単一のベクトルで判断できるような簡単な代物ではなく、様々な要素によって発生する現象です。処理が重いからといって闇雲にハードウェアを増強するのは賢いやり方とはいえません。例えば、メモリ不足が高負荷の原因なのに、CPUを高速なものに変えても効果はほとんどないでしょう。 このような無駄な投資を避けるためにも、負荷の原因を特定して素早く対応策を講じるのはサーバ管理者にとって重要なスキルになります。記事ではサーバ負荷の特定の仕方と対策の仕方について、簡単な概要を説明します。

  • [ThinkIT] 第3回:運用管理を各種ツールで自動化 (1/3)

    Webサービスは、サービスそのものを作るよりも運用の方がコストがかかるといわれています。このため、コストを削減するには運用部分を極力自動化する必要があります。 そこで今回はオープンソースソフトウェアを利用し、コスト削減と運用監視の両面を目的とした手法を紹介します。 一口に「監視」といっても、サーバを運用する際に注目すべき点は様々です。実際にウノウでは、以下のような項目を監視しています。 日々のパッケージのアップデート アプリケーションの脆弱性などの確認やアップデートを行います。 サーバの生存監視 正常にサービスが提供されているかの、サーバの死活を監視します。異常があった場合は即座に通知されるのがベストです。 サーバのリソース監視 サーバがどの程度のリソースを使用しているかを監視します。サーバの負荷測定、ボトルネック検証や増強計画などで効果を発揮します。 アプリケーションのログ監視 アプリケ

  • 1