サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
マンガワンのサーバー 実は過去にプレスリリースの下の方にしれっとスペックを書いたことがあります。 ベアメタルなサーバー大好きクラスタとかの人が話題にしてくれないかなーと思っていたのですが、 私が観測可能な反響は無でした。 もうこの記事の需要の無さが推測されるようではありますが、意図を解説しましょう。 XeonGold 6244というCPUはコア数が少なく、クロックが高く、 最近Apple M1で話題のシングルスレッドの能力が高いモデルです。 マンガワンのサーバーではCPUを4つ搭載することで、コア数の少なさをゴリ押しで解決しており、 会社のフラッグシッププロダクトらしい予算の潤沢さが伺いしれます。 また、マンガアプリなのでSSDは搭載量が多いのですが、Optaneの1.5TBを2本搭載しており、 1本を/tmpやアクセスログ、DBのトランザクション一時ファイルの置き場所に、 もう1本をマ
海外からDDoS攻撃してくるカメラをシャットダウンしてしまうのは不正アクセスなのか?自首してみたが返答がない!そして泥沼のDDoSへ 顛末を記録した雑多なログになっているので整理されていない部分が多々あります. 2万文字を超えているので気合を入れて読むか適当に読み飛ばしてください. これでも不要な調査データを省いたりしてスリム化したのですが超巨大化してしまいました. 2018-11-07から自宅のネットワークの調子が悪すぎる 自宅のネットワークが死んでいました. J:COMの回線現在98%パケットロスするという状態になっています pic.twitter.com/Vfe0O3p5j2 — エヌユル (@ncaq) 2018年11月7日 今日の私 14時 サーバが落ちていることが通知される,サーバにDHCPがアドレス振ってくれてない 15時 ucomがついに死んだかと思いjcomに移行する 1
10年以上金融機関で働いているインフラエンジニアの落ちないサーバにするための考察です。 ハードウェアの専門家ではないので、正確ではないかもしれません。 今までの経験からの個人的考え方になります。 私たちオンプレ重視のインフラエンジニアは、 クラウドサービスではできない高可用性サーバを導入したり、 複数台構成で１台故障しても問題ない構成のサーバはコスト重視するなど、 システムに最適なサーバを導入しようとしています。 高可用性サーバを追求する目的 ■アプリに影響を与えないように Active/Standby構成にしていて、インフラ的にはダウンタイムが数秒だとしても、 アプリによっては復旧に時間がかかったり、問題ないことの確認にも時間がかかってしまいます。 また、正しくサーバが落ちればアプリが問題ないとしても、 サーバが中途半端な状態のままになってしまい、なんだかおかしいということもあります。
★運用終了★Raspberry PiでWebサーバ運用してました！(TOPページ) 2013/01/25 Raspberry Pi1でWebサーバ運用してました！（2013年1月～2018年2月） 2013/09/23 Raspberry Pi1 Webサーバ 障害報告＜運用ミス＋USB充電器の故障＞ 2014/01/02 Raspberry Pi1 Webサーバ 2013年節電結果報告 2014/02/16 Raspberry Pi1 Webサーバ 障害報告＜SDメモリカードの故障＞ 2014/04/05 Raspberry Pi1 Webサーバ 障害報告＜OS障害＞ 2014/04/12 OpenSSL脆弱性対応実施報告 2014/04/28 停電中もサービス継続できました 2014/10/13 稼働状況 2014/11/08 川久保商店サイトリニューアル 2014/11/16 Ras
１日育児体験記事を『日本人の１０００人に１人』が読んでくれた事もあり、記事公開後に三十路男の悪あがきブログが全く表示出来ないという状況に陥りました。 記事を読みに来て下さった皆様、ご不便おかけしてすみませんでした。副業ブログにとってアクセス数は正義。 ブログを表示出来る人を増やす為に、色々な対応を試みました。 最終的にはエックスサーバーに乗せ換え（月額費増加・・・）を選びましたが、色々な施策を打つ中で『アクセス数に応じたサーバーを選ぶ基準』が見えてきたので、今回はその辺りを記事にしていきたいと思います。 サーバー落とし祭り当日育児系の記事は更新初日に200～300読まれたら多い方なので、さくらサーバーのブースト機能を使うという事すら頭にありませんでした。 更新からまもなく『三十路さんのサイト落ちてますよ！！』という連絡を戴きました。 ※この連絡が無ければ１００％気付いていませんでした、
一部のサブシステムの構築で、プロビジョニングツールを捨ててみた。じゃあどうするのかというとシェルスクリプトでやる。今回はこのやりかたが一番楽できるような気がしたので試している。 具体的にはPackerからシェルスクリプトとServerspecを実行してAMIを煮込む。おいしくできあがったらそいつから構築。もしミドルウェアより下の層のコンフィグ類に変更があったらまた煮込む。構築する。新しい方に切り替える。つまり”捨てるインフラ”にする。 プラットフォームはAWS。 (追記)ちなみにchefなどのプロビジョニングツールがめんどくさいからシェルスクリプトにしたというよりは、捨てる前提のサーバだからシェルスクリプトでの構築も選択肢として出てきたということです。ただ自分個人の嗜好としてchefはもう飽きたというのも事実です。なお、オンプレだと同じサーバで継続してプロビジョニングすることになるのでch
「新入社員のための大規模ゲーム開発入門 サーバサイド編」のスライドを公開しました matsuiです。 先週末の2014年6月13日～14日に、札幌でオープンソースカンファレンス 2014 Hokkaidoが行われました。 弊社インフィニットループもスポンサーとして、セミナーの発表を1コマと、ブースを出させていただきました。 その際に使用したスライド資料を公開しましたので、どうぞご覧下さい。 http://www.slideshare.net/infinite_loop/ss-35901898 おかげさまで満席でした。来て頂いた方ありがとうございます。 講師の佐々木、なぜか白衣です（理科の先生に憧れてるらしい）。 ブースはこのような感じです。 新作ゲームである「勇者と1000の魔王」と、Android用のタイムカードアプリである「かざしてシュキーン」を展示しました。 ツイート
お客様各位 さくらインターネット株式会社 平素よりさくらインターネットに格別のご愛顧を賜り、誠にありがとうございます。 下記サービスにおきまして、NTP（Network Time Protocol）の脆弱性を悪用したNTP リフレクション攻撃の事象が多く確認されており、コンピュータセキュリティ関連の情 報発信などを行うJPCERTコーディネーションセンターからも注意喚起が発表されていま す。 ▼対象サービス ・さくらのVPS ・さくらのクラウド ・さくらの専用サーバ ・専用サーバ ・専用サーバPlatform ▼JPCERTコーディネーションセンター 「ntpd の monlist 機能を使った DDoS 攻撃に関する注意喚起」 http://www.jpcert.or.jp/at/2014/at140001.html お客様におかれましては、ntpdへの適切なアクセス制限が設定されている
新規サービス用の監視をNagiosからsensuに切り替えて2ヶ月経ったので、 導入時の調査で社内で公開してたissueと、投入して2ヶ月間運用した記録を公開しておこうと思う。 というか以前Sensuの事を書くと公言していたのに、すっかりサボっていて 昨日@ma0eさんのブログを見て下記のやり取りを思い出して急いで書いた… @ma0e We started usingit. @glidenote willreport the detail soon, I think. — kentaro (@kentaro) 2013, 10月 30 @kentaro @glidenote that would be nice — Mitsutoshi Aoe/maoe (@ma0e) 2013, 10月 30 導入環境はCentOS 6.4で、利用しているsensuのバージョンは0.12.1-1にな
ここ最近のインフラ系技術の流れがおもしろいなー、と思ったので、Puppet が出た辺りぐらいから、振り返って整理してみる。殴り書きなので、後から修正したり書き加えたりするかも。特に後半の方は、あまり考えが整理できてない。 最近のウェブ界隈での「インフラ」という用語の使われ方には、色々異論もあるようだけど、ここではごく最近使われるようになってきた、OS からミドルウェアといったソフトウェアレイヤーを指す言葉としてのインフラについて触れる。（英語圏でも同様の意味で使われているようなので、ある程度市民権を得たと言っても良さそうだし。） プロビジョニングレイヤー まず、前提知識としてプロビジョニングレイヤーと自分が勝手に呼んでるものについて整理。 Chef や Puppet は「プロビジョニングフレームワーク」とも呼ばれているが、以下の議論をより厳密にするために、Lee Thompson 氏による
以前から「誰か書いてくれませんかね」とか言っていた「本当の基礎からのWebアプリケーション入門――Webサーバを作ってみよう」ですが、誰も書いてくれないので自分で書きました。本当の基礎からのWebアプリケーション入門――Webサーバを作ってみよう http://kmaebashi.com/programmer/webserver/index.html 現状、合計で140行くらいのJavaプログラムで、普通に画像やCSSを含むWebページが表示できています。こちらのページの下のほうにも画像を貼っていますが、こんな感じで、ローカルのファイルシステムに置いてある私のWebサイトのトップページが表示できていますし、もちろんリンクをクリックして遷移することもできます。 「えっ? Webサーバってこんなに簡単に書けるの?」と思う人も多いのではないでしょうか。 もちろんこんなのは「わかっている人」から
最近、fluentdという言葉を聞くことが多いと思います。fluentdは、それぞれのサーバからログを収集し集約する為のアプリケーションです。fluentdは「Log everything in JSON」を合言葉に、全てのログをJSON形式で扱います。また一緒に聞くキーワードとしては、大規模とかリアルタイムとかがあると思います。この時点で関係ないやと思って、興味を失った人も多いと思います。しかし、今後のログ管理は、fluentdが主流になるか解りませんが、同様の集約するフレームワークが中心になると思います。 何故、fluentdが必要か？ まずはオンプレミスの世界から見て行きましょう。ログはサーバーにたまり、管理者はサーバにログインしてログを参照します。特に問題はありません。 次にAutoScalingを使わないAWSの世界です。これも同様に、ログはサーバーにたまり、管理者はサーバにログ
はじめまして、運用部アプリ運用グループの清水 勲です。 2011年8月に入社して以来、はじめてエンジニアブログを書きます。 運用部では、日々、mixiを支えるサーバやネットワークを管理、運用しています。 今回は、サーバで使用しているOSの移行について、何回かにわたって紹介したいと思います。 はじめに 突然ですが、mixiで採用しているサーバのOSはなにかご存知でしょうか？ 過去のブログ記事でもあまり紹介していなかったと思います。 はるか前のことなので詳しくは知りませんが、2006年の社外イベントで、弊社からの発表者と質問者との間で、以下のようなやりとりがあったようです。 参加者からの質問 Fedoraを利用している理由は？ 弊社発表者Bさんの回答 他のOSだとNICを認識してくれなかった。Fedoraなら一発でいけたから。 ということで、mixiでは何年も前からFedoraを採用してき
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
