LXCで学ぶコンテナ入門 －軽量仮想化環境を実現する技術 記事一覧 | gihyo.jp第54回Linuxカーネルのコンテナ機能 ―cgroup v2から使うCPUの帯域幅制限（2） 加藤泰文 2023-11-08
第1回 自動文書検査ツールRedPenとは？ | gihyo.jp
はじめに 本連載ではRedPenという自動文書検査ツールの紹介とRedPenを利用した技術文書の校正方法について説明します。RedPenはオープンソースプロジェクトで、現在もゆっくりと開発が続いています。RedPenのホームページは次のとおりです。 http://redpen.cc RedPenは技術文書をターゲットにした文書の自動検査ツールです。技術文書にはマニュアルやチュートリアル、論文、仕様書等が含まれます。この記事のようなソフトウェアツールの紹介文書はもちろん技術文書の一つといえます。第1回の今回は、はじめに技術文書の特徴を解説し、その後RedPenを開発した動機について紹介します。記事の後半では、RedPenの特徴と利用方法について解説します。 技術文書の特徴 RedPenが対象とする技術文書ですが、作文や日記、文学作品等とは大きく異なる特徴をもちます。 最大の違いは、技術文書に
1,000人超の大規模開発者イベント「YAPC::Asia Tokyo 2013」を支えたネットワークインフラ構築の舞台裏～プロフェッショナルのボランタリーが生み出したチカラ｜gihyo.jp … 技術評論社
1,000人超の大規模開発者イベント「YAPC::Asia Tokyo 2013」を支えたネットワークインフラ構築の舞台裏～プロフェッショナルのボランタリーが生み出したチカラ 1,000人を支えたネットワークインフラ 今年9月に開催されたPerl開発者のためのイベントYAPC::Asia Tokyo 2013」。過去最大となるのべ1,000名を超える参加者が集まりました。非常に高い品質のセッションが数多く見られ、gihyo.jp読者の皆さんの中にも会場まで足を運んだ方がいらっしゃるのではないでしょうか。会場では、快適なネットワーク環境が用意され、発表者から聴講者までインターネットを十分に活用できたかと思います。 ここでは、その来場者に向けたインターネット接続サービス提供を実現した専用の会場ネットワーク環境の構築について、準備から当日の模様までを紹介します。 リアルの熱気とネットの熱気の
第6回 ガジュアルなナレッジ共有でクラウドサービスを使い倒す～AWS（Amazon Web Services） Casual Talks | gihyo.jp
IT勉強会を開催するボクらの理由 第6回ガジュアルなナレッジ共有でクラウドサービスを使い倒す～AWS（Amazon Web Services） Casual Talks IT勉強会に突撃レポートし、開始のきっかけや、運営ノウハウなどについてお聞きしていく本連載。第6回目はAWS（Amazon Web Services）の使用事例やノウハウについて、現場のエンジニアがガチで語る勉強会「AWS Casual Talks」をご紹介します。2013年11月1日（金）に開催された記念すべき第1回目の勉強会は、50名の参加枠がわずか15分ほどで埋まり、最終登録者数は210名にまで上ったという盛況ぶり。当日キャンセルもほとんどなく、会場のアマゾン データ サービス ジャパン（以下アマゾン社）会議室では、終始ガジュアル（ガチ＋カジュアル）なトークが繰り広げられました。 告知後わずか15分で申込み枠が一杯に
第278回 Ubuntuカーネルとの付き合い方：Ubuntu Weekly Recipe｜gihyo.jp … 技術評論社
コンピューター上でUbuntuを動かすために必要になるLinuxカーネルは、Ubuntuにおいてもっとも重要なコンポーネントです。今回はそんなLinuxカーネルとUbuntuの関係について説明します。 Ubuntuカーネルのことを知ろう Ubuntuは「Linuxカーネル」を使ったLinuxディストリビューションの1つです。どのようなマシンのうえでUbuntuが動作するか、どのようなデバイスをUbuntuで使えるかは、ひとえにカーネルに懸かっているために、Ubuntuではサポート期間やサポート対象、導入する新機能などを考慮したうえで、LinuxカーネルにUbuntu独自の変更を加えてリリースしています。 たとえば、現在Ubuntuで使われているカーネルのバージョンは、次のコマンドで確認できます。 $ uname -rv 3.8.0-25-generic #37-Ubuntu SMP Thu
第17回 Webアプリケーションのパフォーマンス改善（1） | gihyo.jp
大きな効果を上げるために チューニンガソン#1～#3の改善率を見ると、アプリケーションや全体のアーキテクチャに手を入れないで改善できるのは最大でも10倍以下です。もちろん数倍速度が違えばサーバ台数を大きく減らせるので有意義なのは間違いないのですが、ISUCONやチューニンガソン#4のような飛躍的な高速化は望めないことがわかります。 つまりチューニングでは、単にパラメータ設定を変更するのみではなく、ボトルネックになっているコードやクエリ、アーキテクチャに的確に手を入れていくことで大きな効果を上げることができるのです。 ボトルネックの発見と解消が大事 システム全体の処理時間についてパレートの法則（経験則）を適用すると、「全体の処理時間の80％は20％の部分で発生している」ということになります。実際にシステム全体で一番ボトルネックになっている部分を解消しないことには、ほかの部分に手を入れても大
第1回 バーストトラフィックの発見と対処 | gihyo.jp
はじめに 初めまして、（株）ミクシィの中野和貴です。私はシステム本部運用部インフラグループネットワークチームという部署で働いており、ほかのメンバーと共にmixiのネットワーク部分全般に関して設計・保守・運用を行っています。ここでは『WEB+DB Press』Vol.50～55にて連載されていた「大規模Webサービスの裏側」で紹介しきれなかったエピソードや、その後のインフラ事情を紹介していきます。 日々大量のトラフィックが流れるmixiのネットワークですが、大きくなってくるとやはりいろいろな問題も出てきます。今回はそれらの問題の中で普段運用しているとなかなか気付きにくいバーストトラフィックに起因する問題事例を紹介します。 ミクシィのネットワーク構成と問題の発覚 mixiでは主要なネットワーク機材にはお金をかけていますが、サービス規模からどうしてもラック数が多くなってしまうため、エッジスイッ
第3回 オブジェクト検出してみよう | gihyo.jp
第1回、第2回と画像認識の基礎とOpenCVについて紹介してきました。第3回目の今回は、いよいよ本連載の目玉であるOpenCVを使ったオブジェクト検出に挑戦してみます。 オブジェクト検出の仕組み 基本原理のおさらい オブジェクト検出のプログラムを書き始める前に、そもそもどんな仕組みでオブジェクト検出を行っているのかを理解しましょう。 第1回では画像認識の原理として、学習フェーズと認識フェーズがあることを説明しましたが、OpenCVに実装されているオブジェクト検出プログラムもこの流れに従います。つまり、画像から特徴量を抽出し、学習アルゴリズムによってオブジェクトを学習します（詳しくは第1回を参照してください）。 図1 画像認識の流れ OpenCVに実装されているオブジェクト検出プログラムは、Paul Violaらのオブジェクト検出の研究［1］をベースに、Rainer Lienhartらが
第40回 MOPS：安全性の高いパスワードハッシュ作成ツール - phpass | gihyo.jp
第32回 PHPセキュリティ月間（Month of PHP Sercurity）で「PHPセキュリティ月間」（MOPS - Month of PHP Security）について簡単に紹介しました。 今回はパスワードを安全に保存するツールの紹介です。今まで数回に渡ってMOPSの成果の一部を紹介してきましたが、今回で最後です。 MOPS Submission 10: How to manage a PHP application’s users and passwords http://www.php-security.org/2010/05/26/mops-submission-10-how-to-manage-a-php-applications-users-and-passwords/index.html この論文は1位を取得した論文です。Drupal 7でこのライブラリが利用されてい
第3回 Cassandraのデータモデルを理解する | gihyo.jp
前回までの説明でCassandraのインストールと動かすところまでいきました。今回はCassandraのデータモデルを理解して、実際にデータにアクセスしてみましょう。 データはすべて4次元または5次元の連想配列 Cassandraのデータは非常にシンプルなデータモデルを持っています。データはすべて4次元または5次元の連想配列のようになっています。 4次元の場合は以下の形で値にアクセスします。 ［キースペース］［カラムファミリ］［キー］［カラム］ そして5次元の場合は以下の形でデータを特定します。 ［キースペース］［カラムファミリ］［キー］［スーパーカラム］［カラム］ Cassandraのデータモデルは以下の4つの概念で成り立っています。 カラム： データの最小単位。実際のキーと値、そしてタイムスタンプを持つ。 スーパーカラム： カラムの集合を扱う単位。 カラムファミリ： カラムまたはスーパ
第8回 インフラエンジニアの「修羅場」事件簿 | gihyo.jp
今回は、前回予告した通り、筆者が経験したことのある修羅場について書いてみます。なかなか微妙な内容で、セミナーとかパネルディスカッションとか（飲みの席とか）では話したことはあるのですが、字にするのはたぶん初めてです。 普通修羅場というと、技術的なトラブルに関するものだと思うのですが、ある程度の経験値を積むと、対処できない技術的なトラブルというのはなくなるものです。もし対処できない技術的なトラブルがあるとすると、もうそれは誰にもどうにもできないので諦めるしかないとかになります。ここであえて「技術的な」と書いたのは、意味があります。筆者が経験した修羅場は技術的なものではなく、法的というか金銭的なものでした。 ［Case1］ネットワーク機器差し押さえでルータ13台→4台に まず1つめは、あるデータセンターの運用をサポートというか代行していたときのことです。そのデータセンターは実は購入しているネット
#23 えとらぼ 衛藤バタラ、廣瀬正明、大沢和宏、松野徳大 | gihyo.jp
2006年4月以来、4年間に渡った本連載、今回で最終回となりました。トリを飾るのは、写真ストレージサービス「Ficia（フィシア）」を開発しているえとらぼ（株）代表取締役の衛藤バタラさんと開発部の廣瀬正明さん、大沢和宏さん、松野徳大さんです。少数精鋭を地でいく面々に、会社の生い立ちからインタビューが始まりました。 撮影：武田康宏 新たに会社を始めた理由 弾：本連載でいろんな方をインタビューしてきたんですけど、バタラさんはたぶん僕と一番境遇が近いんですよ。上場させた会社でCTOをやって[1]、そこを辞めて。その後は、僕は1人で好きなようにやってますけど、バタラさんはまた会社を始めましたよね。その理由は？ 衛藤バタラ（以下、バ）：会社というより、サービスを作りたかったんです。世の中にあるいろいろな写真ストレージサービスを見ていると、こうだったらいいのにと思うことがあって、それを形にす
OpenSocialを利用してガジェットを作ろう！ 記事一覧 | gihyo.jp
運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します。個別にライセンスが設定されている記事等はそのライセンスに従います。
第5回 サーバ屋 vs. ネットワーク屋のレイヤ2戦争 | gihyo.jp
巨大なネットワークの弊害 「1つのブロードキャストドメイン内に設置する端末の数は100台まで」といったガイドラインをよく耳にします。100という数字が妥当かどうかはともかく、ブロードキャストドメインを適切な大きさで分割しなければいけないのは間違いないですね。 たとえば、インターネット全体が1つのブロードキャストドメインだったら、どうなりますか？ 地球の裏側のWebサーバへ接続するのにも、いちいちARPを飛ばすことになり、ネットワークがARPパケットであふれてしまいます。また、PCなどの端末はブロードキャスト（宛先がオールFのMACフレーム）を受信すると、自分に関係のある情報かどうか判断するために多少のCPUパワーを消費してしまいます。 たとえるなら、メーリングリストに投稿されたメールのようなものです。メールを受け取った人は、自分に関係のある内容かどうか判断するためにメールを少しは読まなけれ
えとらぼ、kumofsをオープンソースにて公開 | gihyo.jp
2010年1月18日、えとらぼ株式会社は同社の写真ストレージサービス「Ficia」に採用されている、分散型Key-value Store「kumofs」を、Apache License 2.0のもと、オープンソースとして公開することを発表した。 kumofsとは？ kumofsは、レプリケーション機能を実装したKey-value Store（データを「Key」と「Value」の組み合わせで格納するソフトウェア）。kumofsを採用したシステムの場合、一部のサーバに障害が発生しても、システム全体は正常に動作し続けることができる。さらに、自動的に複数のサーバに負荷を分散するため、トラフィックの増減に対し柔軟な対応ができ、高いスケーラビリティを実現する。 詳細はえとらぼのgithubを参照。 kumofs URL：http://code.etolabo.com/kumofs
第4回 memcachedのCASとmixiでの運用動向 | gihyo.jp
今まで簡単に触れてきたmemcachedのCAS（Compare and Swap）機能ですが、今回はその具体的な使用例や、プロトコルの違いによる特徴を紹介します。また、mixiでの今後のmemcached運用動向を紹介します。 CASの概要 memcachedには特定のデータに対してアトミックな更新を試みる機能が存在します。この機能の仕組みは単純で、クライアントは特定のコマンド（テキストプロトコルの場合は“gets”）を実行することにより、サーバから特定のレコードとその状態を表すユニークな識別子を与えられます。 この識別子はレコードが何らかの手段によって更新されると変更され、クライアントが保持している識別子とは別の値になります。したがって、クライアントは与えられた識別子を更新命令と一緒に送信することで、サーバはレコードをアトミックに更新できるかを確認することができます。もし識別子が
第3回 Kaiの詳細（1） ─Kaiの要であるクラスタを極める | gihyo.jp
前回、Kai のインストールと基本的な使い方を説明しましたので、今回は、Kai最大の特徴であるクラスタついて詳しく説明します。 なお、前回同様、本連載が対象とするKaiのバージョンは0.4、ErlangのバージョンはR13Bです。 データの保存・取得とリクエストの転送 memcachedでは、クライアントがデータの場所を決定します。このため、クライアントは、クラスタを構成するすべてのmemcachedノードを把握していなければなりませんでした。 一方Kaiでは、ノードがデータの場所を決定し、クライアントからのリクエストを適切なノードに転送します。クライアントは、すべてのノードを把握する必要がありませんし、L4ロードバランサで機械的に負荷分散することもできます。また、クラスタへノードが追加されても、クライアントのノード一覧を修正する必要がありません。 では、前回、構築した3ノード構成のクラス
第2回 Desktop CDを使いこなす（1）：USBメモリとの併用・LiveCDのカスタマイズ | gihyo.jp
Ubuntuのデスクトップ向けインストールCD（Desktop CD）は、LiveCDとなっています。今回と次回は、これを使いこなす方法について説明します。 Desktop CDの概要 LinuxのLiveCDの実装は複数存在しますが、現在のUbuntu Desktop CDではSquashFSをCD上に置き、UnionFSでWritableにする、という方法を取っています[1]。 Desktop CDが提供するソフトウェア環境は、HDDへインストールした後に利用できるものと同じで、SquashFS部分は「UbuntuをHDDにインストールした初期状態」と同等のものを圧縮したものを用いています。ただし、インストールに用いるUbiquityやGNOME Partition Editor（gparted）といったツールが導入されている点と、異なるマシンで起動させるため、起動時に自動的にXの設
2008年9月26日号 Intrepid Alpha 6のリリース、Lauchpad 2.1.9、LaunchpadとPPAの使い方、オープンソースカンファレンス | gihyo.jp
Ubuntu Weekly Topics 2008年9月26日号Intrepid Alpha 6のリリース、Lauchpad 2.1.9、LaunchpadとPPAの使い方、オープンソースカンファレンス Intrepid Alpha 6がリリースされました 9月19日にUbuntuの次期バージョン“Intrepid Ibex”のテスト版であり、最後のアルファ版でもあるAlpha 6のリリースがアナウンスされました。ただし、Intel GigE用のe1000eドライバを使う環境では、ファームウェアを破壊する可能性があるため、該当の環境ではAlpha 6を使わないよう告知されています。この件に関する詳しいことは、こちらをご覧ください。 今回明らかになった変更点は以下のとおりです。 Sambaが3.2ベースとなりました。IPv6の対応やGNU v3へのライセンス変更など、多岐に渡る修正・新機
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
memcached座談会 記事一覧 | gihyo.jp