タグ

ブックマーク / gihyo.jp (12)

  • 2016年5月30日 ログアウトのたびにユーザプロセスをすべてkillなんて ―毎度お騒がせのsystemd、新バージョンでまた炎上 | gihyo.jp

    Linux Daily Topics 2016年5月30日ログアウトのたびにユーザプロセスをすべてkillなんて ―毎度お騒がせのsystemd、新バージョンでまた炎上 誕生以来、Linuxユーザの間で好き嫌いが大きく分かれるプログラムの代表にsystemdがある。現在、メジャーなLinuxディストリビューションのほとんどはデフォルトの起動プロセスとしてsystemdを採用しているが、その変更を決めるときはたいてい、どのコミュニティでもひと悶着がつきまとう。たとえば2年前にDebianがsystemdへの移行を決定したときも、開発者の間で意見が二分された状態になり、最後はチェアマンの裁定でsystemdに落ち着いている。また昨年、UbuntuがUpstartからsystemdに移行した際も、多くのユーザや開発者が混乱に陥ったことは記憶に新しい。 そしてそのsystemdがそのアップデート

    2016年5月30日 ログアウトのたびにユーザプロセスをすべてkillなんて ―毎度お騒がせのsystemd、新バージョンでまた炎上 | gihyo.jp
    blueskies
    blueskies 2016/05/30
  • YAPC::Asia Tokyo 2015 1日目レポート[更新終了] | gihyo.jp

    20日から22日までの3日間、東京ビッグサイト 会議棟にて「YAPC::Asia Tokyo 2015」が開催されています。日は1日目。稿では、この1日目の模様を随時レポートしていきます(注:すべてのセッションをレポートするわけではありません⁠)⁠。 日の受付は会議棟7階でした。参加者の皆さんは開場前からたくさんの方がロビーで待っていました。 Daisuke Makiさん「Opening」 オープニングの挨拶は、JPA director/YAPC::Asia 2015実行委員長の牧大輔さんです。この日を迎えられて感無量とのことです。なお前夜祭には、運営側の予想を超える500名の来場者がいたそうです。 まず、会場の諸注意を話しました。トラックAの国際会議場では飲禁止、その他トラックの会場では事は禁止ですが、飲み物は気を付ければ飲んでも大丈夫とのことです。 また今回のイベントでは、英

    YAPC::Asia Tokyo 2015 1日目レポート[更新終了] | gihyo.jp
    blueskies
    blueskies 2015/08/21
  • YAPC::Asia Tokyo 2015 前夜祭レポート[更新終了] | gihyo.jp

    2015年8月20日(木)から22日(土)までの3日間、東京ビッグサイト 会議棟にて「YAPC::Asia Tokyo 2015」が開催されています。日は前夜祭。稿では前夜祭の模様を随時レポートしていきます。 受付など 前夜祭ではトラックDとトラックEでセッションが開催されます。 参加受付は東京ビッグサイト会議棟6階にあります。開始50分前ですが、すでに参加者で賑わっています。 受付自体は機械にQRコードを読み取らせるだけです。 前夜祭はアルコールを含めフリードリンクやお菓子が提供されています。トラックD会場の入口付近には、フリードリンクで「YAPC」の文字が形作られていました。 今年のスタッフはアロハシャツを着ています。なにか分からないことがあれば気軽に聞いてみましょう。 今年の前夜祭は2トラックなので、前夜祭自体の開始の挨拶はなく、諸注意のアナウンスの後、セッションが始まりました。

    YAPC::Asia Tokyo 2015 前夜祭レポート[更新終了] | gihyo.jp
    blueskies
    blueskies 2015/08/21
  • 第8回(最終回) 定型作業を自動化するConsul Template | gihyo.jp

    Consul Template これまでの連載の応用として、最後にConsul Templateをご紹介します。SerfやConsulを使えば、複数台のサーバやLinuxコンテナ上で、様々な処理を同時に行うことができます(イベントハンドラ機能⁠)⁠。実行は任意のタイミングで行えるだけでなく、ノードの増減やサービスの増減に応じて自動的に実行できることが特徴です。 自動実行は、増減のタイミングでコマンドを実行するだけでなく、管理用のファイルやロードバランサ等の設定ファイルを書き換えにも利用できます。通常は、設定を書き換えるためのスクリプトやプログラムを準備する必要がありました。 この設定ファイルの自動書き換えに特化したプログラムがConsul Templateです。その名前の通り、Consulクラスタと連携します。あらかじめテンプレート元になるファイルを用意しておくことで、Consul上でのノ

    第8回(最終回) 定型作業を自動化するConsul Template | gihyo.jp
    blueskies
    blueskies 2015/06/02
  • 第7回 Consulのオーケストレーションと自動化 | gihyo.jp

    これらはChefやPuppetのような構成管理ツールを使うような状況と似ていますが、少し異なります。構成管理ツールの場合は、設定時点において対象となるサーバ上のサービスが正常かどうかを判断することができません。Consulはサービス検出機能を持っていますので、正常なサービスを稼働している対象のみ、自動的に処理を行うことができます。ただし、決して構成管理ツールが不要になるのではなく、サービス検出と併用することによって、相互に補完し合うこともできます。 Consulのイベントハンドラ Consulのオーケストレーションと呼ばれる機能の実体は、イベントハンドラです。これは、任意のタイミングまたはConsulのサービス検出と連動し、任意のコマンドやスクリプトを自動実行する仕組みです。今回は、一番手軽に利用できるリモート実行機能を見ていきます。 リモートでコマンドを実行するConsul exec C

    第7回 Consulのオーケストレーションと自動化 | gihyo.jp
    blueskies
    blueskies 2015/05/26
  • Socket.IOの作者Guillermo Rauch氏、新開発のファイルアップロードライブラリ「Party」を紹介 ~ 東京Node学園祭2014 基調講演 | gihyo.jp

    Socket.IOの作者Guillermo Rauch氏、新開発のファイルアップロードライブラリ「Party」を紹介 ~ 東京Node学園祭2014 基調講演 2014年11月15日、株式会社 サイバーエージェントセミナールームにて東京Node学園祭2014が開催されました。稿では基調講演の模様をレポートします。 基調講演はNode.jsのリアルタイム通信モジュールであるSocket.IOの作者であり、CloudUpというサービスを開発しているAutomatticのCTO、Guillermo Rauch(@rauchg)氏です。もうすぐ公開されるOSSのファイルアップロードツール「Party」の話を中心に、いまWebに不足している「ファイルアップロード」について話しました。 拡がるSocket.IOの実用例 日のたくさんの会社が何年にも渡ってSocket.IOにパッチを送ってくれていま

    Socket.IOの作者Guillermo Rauch氏、新開発のファイルアップロードライブラリ「Party」を紹介 ~ 東京Node学園祭2014 基調講演 | gihyo.jp
    blueskies
    blueskies 2014/11/26
  • Linuxシステム[実践]入門

    このの概要 書ではLinuxを扱う上で必要となる設定ポイントなどをまとめています。ハードウェアとLinuxの関わり,Linuxカーネルやシェルの理解を深め,設定ファイルや起動スクリプトについて解説します。またApacheやPostfixなどのアプリケーションの他に日語環境やX Windowの設定,認証などについても丁寧に解説を進めています。「Linuxをインストールしたがどのように扱ってよいかわからない」「Linuxはどのような構造で動いているか興味がある」という方にお薦めです。 こんな方におすすめ Linuxの勉強をはじめたい人 Linuxの活用方法を知りたい人 よりLinuxを使いこなしたい人 第1章 Linuxの基礎知識 1-1 UNIXの基礎 1-1-1 ログイン・ログアウト 1-1-2 シェルとコマンド 1-1-3 マニュアルコマンド man マニュアルを参照する manの

    Linuxシステム[実践]入門
    blueskies
    blueskies 2013/07/24
  • 第2回 最大の課題「I/Oボトルネック」の原因と分析法 | gihyo.jp

    I/Oの「レスポンス」と「スループット」とは? 連載第1回でご紹介したように、大規模データ処理を行うデータベースで一番大きな課題となるのは、ディスクI/O(以降、単にI/Oと表記します)のボトルネックです。数百GBやTBクラスの巨大データウェアハウスの場合、SQLが実行される時間のほとんどがI/Oを待つ時間となっているケースが多々あります。 ここでは、I/Oボトルネックが発生するおもな原因を、「⁠レスポンス」と「スループット」という概念から見ていきましょう。それぞれ、広義では以下の定義となります。 I/Oレスポンス=I/O要求処理にかかる応答時間 I/Oスループット=単位時間当たりのI/O処理量 Oracle Databaseに当てはめると、以下のように定義できます。 I/Oレスポンス=1データブロックの読み出しや書き込みにかかる時間 I/Oスループット=単位時間あたりの読み出しや書き込み

    第2回 最大の課題「I/Oボトルネック」の原因と分析法 | gihyo.jp
    blueskies
    blueskies 2013/01/08
  • 第1回 大規模データではRDBMSのどこがボトルネックになるのか? | gihyo.jp

    RDBMSはオワコン? 「右を向いても左を向いても“⁠ビッグデータ⁠”というキーワードが闊歩する時代に、いまさらRDBMSの話題?」 連載のタイトルを見てそう思われたかもしれません。 「ディスクベースのRDBMSはオワコン、これからは○○(お好きなアーキテクチャを入れてください)の時代だ!」 とおっしゃる方もいるかと思います。 しかし、むしろ多くの企業がビッグデータに注目しているおかげで、RDBMS側でも大規模データを取り扱うニーズが増えています。 大規模データを取り扱う時にボトルネックとなる5つのポイント 数百ギガバイトといったレベルのRDBMSであれば、現場のエンジニアの方にとってはあたりまえの世界でしょう。しかし、テラバイトを大きく超えたデータを扱う場合には、ボトルネックの傾向が変化するのはご存じでしょうか。 次の図は、RDBMSにまつわるボトルネックを示したものです。 図1 大規

    第1回 大規模データではRDBMSのどこがボトルネックになるのか? | gihyo.jp
    blueskies
    blueskies 2012/12/17
  • 楽天技術研究所、Webに特化した分散ファイルシステム「LeoFS」リリース | gihyo.jp

    2012年7月4日、楽天技術研究所の原陽亮氏が中心となって開発しているWebに特化した分散ファイルシステムLeoFSが、オープンソースとしてリリースされた。 LeoFS http://www.leofs.org LeoFSは数十億といった大量の画像ファイルを扱うことに長けたファイルシステムで、独自のアーキテクチャにより高パフォーマンスを実現する。 主な特徴は以下のとおり。 ソフトウェアだけでストレージの仮想化(オブジェクトベースストレージ)を実現。PBのストレージクラスタの構築が可能 Amazon S3-API準拠(現行バージョンは基APIのみ) すべての機能は冗長化されており, 単一障害点がなく スプリットブレイン対策が施されている 特別なハードウェアは必要なく、市販されているPCサーバでシステムの構築が可能。また、Linux/Mac OSX/FreeBSDに対応し、OSに特別な設定等

    楽天技術研究所、Webに特化した分散ファイルシステム「LeoFS」リリース | gihyo.jp
    blueskies
    blueskies 2012/07/06
  • Mobageを支える技術 ~ソーシャルゲームの舞台裏~

    このの概要 書は大規模Webサービスの構築・運用ノウハウを詰め込んで一冊にまとめた書籍です。急激に成長する巨大システム『Mobage』がどのように開発され,運用されているのか?その舞台裏を「ソーシャルゲーム(フィーチャーフォン/スマートフォン)」「大規模Webインフラ」「プラットフォーム」「ビッグデータ分析」といったテーマに分け,DeNAの実践的ノウハウを解説しています。 こんな方におすすめ Webサービスの構築・運用のテクニックを知りたい方 著者プロフィール 城戸忠之(きどただゆき) 1989年NTTソフトウェア入社。1999年南場社長がDeNA立ち上げの際に出向,ビッダーズのプロジェクトマネジメントに携わる。自分たちで事業を作ることが楽しくなり,2000年DeNA入社。「みんなのウェディング」「エアーリンク」など,DeNAの数々のプロジェクトに携わる。QualityAssuranc

    Mobageを支える技術 ~ソーシャルゲームの舞台裏~
    blueskies
    blueskies 2012/05/30
  • オープンソースのバウンスメール解析システム BounceHammer | gihyo.jp

    何らかのバウンスメールが返ってきたら、そのメールアドレスを配信不能なアドレスとして扱うという単純なバウンス処理を行った場合、“⁠メールボックスがいっぱい⁠”や“⁠メールが大きすぎる⁠”のようなエラーで宛先アドレスに配信不能フラグを立ててしまうという誤った対処をしてしまう危険性があります。 エラーになった理由ごとに適切な対処をすれば、メールアドレスの状態変化を管理しつつ、宛先不明アドレスの割合増加による遅延を回避ができます。検出できるエラーについての詳細は、http://bouncehammer.jp/features/engine/reasonをご覧ください。 読みにくいバウンスメールを構造化する BounceHammerは解析したバウンスメールの内容をYAML形式で出力します。YAML形式の解析結果は1行1レコードで書き出しているので、コマンドラインからcatで眺めたり、wcで行数計測す

    オープンソースのバウンスメール解析システム BounceHammer | gihyo.jp
    blueskies
    blueskies 2010/12/22
    来年導入するかも?
  • 1