タグ

infrastructureに関するhidex7777のブックマーク (10)

  • 水道料金について誤った情報が流れていますのでご注意ください 松山市ホームページ

    更新日:2016年6月29日 インターネット上で「松山市は水道事業の運営を外国資の企業にすべて委託し、これにより水道料金が値上がりしている」という誤った情報が流れていますので、ご注意ください。 正しい情報は次のとおりです。 水道事業の民間委託について 松山市では、すでに平成16年度から、水道事業の業務のうち「浄水場の運転や設備の保守」について民間委託を行っています。 平成24年4月からのヴェオリア・ジャパン株式会社との委託契約は、平成19年4月から平成24年3月までの契約期間の満了に伴うものです。 この業務委託は、「浄水場の運転や設備の保守」に限られたものであり、水道事業の運営自体を委託しているものではありません。 松山市の水道事業の運営は、これまでどおり、松山市公営企業局が行っています。 また、松山市の水道水の水質管理についても、これまでどおり、松山市公営企業局が責任を持って実施してい

  • 無料Wi-Fi 一度登録すれば全国的に利用可能へ | NHKニュース

    外国人旅行者が公共施設や店舗などに設置されている無料Wi-Fiと呼ばれる無線通信に簡単に接続できるようにするため、一度登録すれば全国的に利用できるよう事業者が連携することを決めました。 このため、ソフトバンクやKDDIの子会社などのWi-Fi事業者は、今月中にも社団法人を作ったうえで、外国人旅行者向けのサービスとして、利用者が一度登録すれば提携する事業者のWi-Fiを利用できるようにすることを決めました。 社団法人は、サービスを利用する際の認証手続きや利用者への注意喚起などセキュリティ対策を検討し、1年後をめどに全国の施設や店舗などでサービスの開始を目指します。複数の事業者が連携して無料Wi-Fiサービスを全国展開するのは初めてとなります。 外国人旅行者の増加が見込まれる2020年の東京オリンピック・パラリンピックに向けて、無料Wi-Fiを使える場所は増え続けています。しかし、利用にあたっ

    無料Wi-Fi 一度登録すれば全国的に利用可能へ | NHKニュース
  • 現代ITインフラの王道をゆくLinuxパッケージ管理の基本構成 | 外道父の匠

    RedHat系におけるRPMパッケージを扱うYUM、Debian系におけるDEBパッケージを扱うAPT、これらはサーバー管理において重要なわけですが、絶妙な度合いで、おざなりに扱ってもわりとなんとか運用出来てしまう感があります。そのため今一度、こんな感じが今風のスタンダードじゃないっすかね(キリッ という構成を説明してみます。 ぶっちゃけ、たいしたことないネタの集合体なので、タイトルに下駄を履かせました。 そもそもパッケージは必要なのか 言うまでもなく必須です。理由は、インストール物のファイル管理が容易になるのと、インストール時間を短縮できるからです。既存のパッケージでconfigureオプションが物足りない時や、RPMパッケージが存在しない場合は作成することになります。 最近はプロビジョニング・ツールによって全て自動化できるので、超簡素なコンパイルのものはレシピに落とし込んで終わりにした

    現代ITインフラの王道をゆくLinuxパッケージ管理の基本構成 | 外道父の匠
  • 若手インフラエンジニア現状確認会 #wakateinfra に参加したまとめ - rrreeeyyy.com

    若手インフラエンジニア現状確認会 #wakateinfra に参加したまとめ Feb 23, 2015 若手インフラエンジニア現状確認会に参加してきた。とにかく最高だった。 若手インフラエンジニア現状確認会 きっかけはこれです。 @rrreeeyyy @deeeet @y_uuk1 飲み会しよ pic.twitter.com/zUehyYnP7v — okumura takahiro (@hfm) 2015, 1月 22 Mackerel Meetup #3 Tokyo に参加した辺りで若手少ないかつ交流そんなにないよね、みたいになって開催が決定した。 あれよあれよという間に各社から有名若手がバンバン集まってきてこの中に居ていいのか…みたいな気分はあったんだけど、参加してみたらとにかく最高だった。 資料 各人の発表資料(無い人もいる)とちょっとしたまとめ、思ったことを付しておく。 ペパボ、

    hidex7777
    hidex7777 2015/02/24
    「筋肉運用」ww今日からつかおう。あとNoOpsもいい言葉。
  • 負荷低すぎはもはや障害じゃないのか - mikedaの日記

    前のブログの続きで、もにかじ7で話した小ネタその2。 実際にサービスでなんかやったというのじゃなく、こういうこと考えてるんだけどみんなどうしてます?って話です。 まずオンプレ時代はサーバのスペックダウンはけっこう大変だったし、頑張ってメモリやCPU引っこ抜いてもそんなに節約にならなかった。 ※CPUやメモリはサーバ価格の一部でしかないし、ラック費用(消費電力)もあるし。 でもクラウド前提だとスペックダウンはとても簡単で、スペック半分にすると価格も半分になる。 そうすると、 『イベントで一時的にc4.4xlarge(8万/月)にして、そのまま最大CPU使用率10%とかで数ヶ月放置されている』 みたいなのはビジネス的な損失という意味で明らかに障害で、監視すべきじゃないだろうか? みんななんかやってますか? というようなことを参加者に聞いてみました。 参加者の中では、AutoScalingしてい

    負荷低すぎはもはや障害じゃないのか - mikedaの日記
  • Webエンジニアが目を通しておきたいインフラの基本の本 - たごもりすメモ

    「Webエンジニアが知っておきたいインフラの基」を著者の馬場さんから献いただきました*1。ありがとうございます。 ITインフラの設計やら構築やら運用やらに関わりながら仕事をするようになってそれなりの年数になった。日頃おろそかにしている部分もあれば専門だと思って自信をもってやれることもある。その中でたまに思うのは、何が当たり前で何は当たり前ではないのか、ということがよくわからなくなってきたなあ、ということだ。 障害対応時の心構えは? そもそもシステムメンテナンスにおける心構えとは? Webアプリケーション基盤の設計方法は? 非機能要件にはどのようなものがあるか? パフォーマンスとは何を指すのか? どんなサーバにも入っているツールで調べものをするときの鉄板は? サーバのパフォーマンスを示すグラフの見方は? どのような兆候が出ていたら注意しなければならないのか? どの数字にどういった意味があ

    Webエンジニアが目を通しておきたいインフラの基本の本 - たごもりすメモ
  • Ansibleを使い出す前に押さえておきたかったディレクトリ構成のベストプラクティス - 双六工場日誌

    Ansibleのディレクトリ構成を決める際、プロダクション環境、ステージング環境、開発環境といった環境ごとに異なる設定を変更する方法でしっくり来るものを思いつかず、どうしたものかと悩んでいたのですが、今日見つけたブログ記事でそれもスッキリ解消したのでメモっておきます。 結論 まず結論を。プロダクション環境、ステージング環境、開発環境といった環境ごとに異なる設定する場合は、以下のように対応するのが良さそうです。 ディレクトリ構成は、公式ドキュメントに従う。 Best Practices — Ansible Documentation プロダクション、ステージング、開発など、ステージごとの変数切替は以下のブログを参考に、"group_vars"を利用して行う。 インベントリファイルの中に、"[production:children]"のようなグループすべてが属するグループを作ってしまい、そのグ

    Ansibleを使い出す前に押さえておきたかったディレクトリ構成のベストプラクティス - 双六工場日誌
  • 小さなサーバーで大きなサービスをつくる | カメリオ開発者ブログ

    アーキテクトのItoです。動画を撮るのが趣味ですが、最近はこのを買って、カラーグレーディングの勉強をしています。とても良いです。 さて、今回お話するのはバックエンドにあるフロントエンドについて。 以下はほぼ実際にカメリオで運用しているバックエンド構成です。 図中のサーバーというものはいわゆるHTTPベースのサーバーアプリで、ここでは緑をNode.js, グレーをPython, C++で実装しています。小さいサーバーがたくさんあります。主にクライアント〜フロントエンドAPIだけの構成図で、記事クローラーや各種管理画面などは図にはありませんが存在します。 まずフロントエンドにELB(AWSを使用)とNginxを置き、後ろに NodeベースのフロントエンドAPIサーバーを置きます。 ここはNode.jsで作られたアプリをサービスするごく一般的な方法です。 エンドポイント(api.kamel.

    小さなサーバーで大きなサービスをつくる | カメリオ開発者ブログ
  • Reverse Proxyがなぜ必要か、勝手に補遺 - たごもりすメモ

    「全体のリソース効率を上げましょう」というためのものである。 Reverse Proxy がなぜ必要か - naoyaのはてなダイアリー これは完璧に正しくて、ただ「リソース効率」という概念はあまり具体的な想像が追い付かない人がいそうだなと思ったので、ちょっとだけ補足しようと思った。 Reverse Proxyを入れることでリソース効率の向上を狙うんだけど、それは以下のような複数の場面におけるそれぞれのリソース効率向上を複合的に狙うものだ。 通常時のトラフィック配信におけるCPU・メモリ使用率を最適化する バースト時(過負荷時)のトラフィックをより細かく制御可能とする 障害時におけるダウンタイムおよび総合的な計算・配信能力の低下を極小化する 多数のサーバによる構成全体を増強・入れ替え・移動あるいは削減する際の自由度の向上を狙う 簡単にコンピュータの性能だけで言うと最初の項目だけをリソース効

    Reverse Proxyがなぜ必要か、勝手に補遺 - たごもりすメモ
  • 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のはてなダイアリー
  • 1