元RX-7乗りの適当な日々 このページをアンテナに追加 RSSフィード Twitter

RX-7(FD3S)WRX STI関連のキーワードで検索されて来られた方へ。
右サイドのカテゴリ『』をクリックすると関連する項目だけが表示されます。
日々の写真は『Flickr』で公開しています。

2014/12/31

WRX STI

"元RX-7乗りの適当な日々"の2014年人気エントリランキング


2014年も残すところ、あと数時間。すっかり年の瀬です。今年も当ブログへアクセスいただき、ありがとうございました。

今年も例年通り、まとめの意を込めて、当ブログでの2014年のアクセスランキングを残しておきます。


今年の当ブログへのアクセス数(PV数)を確認してみると、今年もPVの下降傾向が続き、昨年(2013年)比で約14%減という結果でした。ただ今年の10月1週目頃から、デイリーPVが例年通り(2年前頃)まで戻って来ていますので、何らかのパンダアップデートがあったのかもしれません。

例年通りではありますが、過去に書いたエントリへのアクセス数がそれなりに上位を占めていますので、例年同様、2014年に書いたエントリのランキングと、ブログ全エントリに対する2014年アクセスランキングの両方を残しておきます。

ちなみに、過去のランキングは以下のエントリを。


まずは、2014年に書いたエントリに絞ったランキングBEST10から。


1. Linuxで使っているNICのドライバやバージョンを調べる方法いろいろ


2. auの3円/月ガラケーとドコモのMVNO SIM + iPhone6を使う運用に変更した


3. 「開発効率をUPする Git逆引き入門」を読んだ


4. 「Zabbix統合監視 徹底活用」を読んだ


5. 複数のWebサーバでSSLセッションキャッシュを共有してSSL処理を高速化(Apache + mod_ssl + mod_socache_memcache)


6. 「JVM Operation Casual Talks」発表資料のリンクをまとめてみる #jvmcasual


7. Redis(2.8系)の基本オペレーションとかSentinelの挙動とかの色々メモ


8. 「Chef実践入門」という書籍を出します


9. Quaggaを使ってLinuxサーバで動的ルーティング


10. デブサミ2014「サーバプロビジョニングのこれまでとこれから」講演メモ #devsumi


ちょっとこのエントリが1位になるとは想像もしていませんでした。1月に書かれたエントリで11月に書かれた2位のエントリと勝負するのは、ちょっとフェアではありませんが、まあこれが結果という事で。




次に、ブログ全エントリに対する2014年内のアクセスランキングです。

例年の傾向ではありますが、2014年に書いたエントリに限らず、それ以前の過去エントリの閲覧数が全体的に非常に多くなっています。(2014年のエントリはベスト10内で2つ。)


1. 様々なLinuxのOSバージョンを確認する


2. psコマンドでスレッドを表示させたり、スレッドごとのCPU使用率を確認する


3. 新しい車を買いました「WRX STI tS」


4. Linuxサーバがディスク容量不足になった!何か消さねば!ってなった時にどう対処するか


5. Linuxで使っているNICのドライバやバージョンを調べる方法いろいろ


6. ある文字列をファイルの特定行に挿入するコマンド


7. 大容量ファイルのSCP転送を高速にする方法


8. auの3円/月ガラケーとドコモのMVNO SIM + iPhone6を使う運用に変更した


9. リモートデスクトップでアクティブウィンドウのスクリーンショットを取得したい場合 (リモートデスクトップの特殊キー一覧)


10. はじめてのAmazon VPC - 1. ルーターからVPCへVPN接続する


次点




・・・と、2014年の当ブログはこんな感じでした。

今年も1位だった「様々なLinuxのOSバージョンを確認する」は6年以上前のエントリですが、過去5年は当ブログで2, 2, 1, 1, 1位とアクセスを集めているエントリです。

メモ的に書いた内容ではありましたが、結果として多くの方に少しでもお役に立てたと思うと嬉しい限りです。これからも当たり前のような内容のメモエントリであっても積極的にログとして残していきたいなと思っています。


では、今年はこれが最後のエントリとなります。どうぞ、来年もよろしくお願い致します。

それでは、よいお年を!=͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́


関連リンク



2014/12/22

Linuxでストライピング(RAID0)なソフトウェアRAIDを組んでいた際にデバイスが外れてしまった場合


若手が(ry・・・シリーズ。次から他の人にやってほしいのでw 共有用のメモを残してしておきます。

Linuxのサーバで、ソフトウェアRAID(ストライピング)を組んでいたときに、片方のデバイスが不調で外れてしまったんだけど、デバイス内のデータは無事で、復旧(RAID0再構成)させたい場合のオペレーション。


ちなみに、たまたまなんだけど、ちょうど8年くらい前に似たようなエントリを書いていた。参考までに。


RAIDデバイスの確認

外れてしまったデバイスは、問題なさそうってのは確認済み(本エントリでは割愛)で、あとは正常なRAIDデバイスに戻したいフェーズ、ってのが前提。

(自分が作ったサーバではないので、アレやコレやと確認しながら手探りになってしまっていますがw)


# cat /proc/mdstat
Personalities : [raid0]
md0 : inactive fiob[1] fioa[0]
      1249999872 blocks super 1.2

unused devices: <none>

mdstat見ると、inactiveになってますねー。


# mdadm --detail /dev/md0
/dev/md0:
        Version : 1.2
  Creation Time : Thu Jun 28 14:38:32 2012
     Raid Level : raid0
   Raid Devices : 4
  Total Devices : 2
    Persistence : Superblock is persistent

    Update Time : Thu Jun 28 14:38:32 2012
          State : active, FAILED, Not Started
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0

     Chunk Size : 256K

           Name : servername:0  (local to host servername)
           UUID : d1b36e91:11335546:3afa068c:35bcb74b
         Events : 0

    Number   Major   Minor   RaidDevice State
       0     252        0        0      active sync   /dev/fioa
       1     252       16        1      active sync   /dev/fiob
       2       0        0        2      removed
       3       0        0        3      removed

詳細を確認。デバイス4本でRAID0だったところ、2本のデバイスが切り離された状態となっている。


# mdadm --manage /dev/md0 --add /dev/fioc
mdadm: /dev/fioc reports being an active member for /dev/md0, but a --re-add fails.
mdadm: not performing --add as that would convert /dev/fioc in to a spare.
mdadm: To make this a spare, use "mdadm --zero-superblock /dev/fioc" first.

カジュアルにaddしようとしてもダメと。中身というかSuperblockが残っていますからね。そりゃそうです。


# mdadm --manage /dev/md0 --re-add /dev/fioc
mdadm: --re-add for /dev/fioc to /dev/md0 is not possible

一応やってみた、、、けど、ダメですw



# mdadm --examine /dev/fioa
/dev/fioa:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x0
     Array UUID : d1b36e91:11335546:3afa068c:35bcb74b
           Name : servername:0  (local to host servername)
  Creation Time : Thu Jun 28 14:38:32 2012
     Raid Level : raid0
   Raid Devices : 4

 Avail Dev Size : 1249999872 (596.05 GiB 640.00 GB)
    Data Offset : 2048 sectors
   Super Offset : 8 sectors
          State : clean
    Device UUID : 6c5bac62:4ceb9b5a:93dae9f9:9ff609c6

    Update Time : Thu Jun 28 14:38:32 2012
       Checksum : c44265b4 - correct
         Events : 0

     Chunk Size : 256K

   Device Role : Active device 0
   Array State : AAAA ('A' == active, '.' == missing)


# mdadm --examine /dev/fiob
/dev/fiob:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x0
     Array UUID : d1b36e91:11335546:3afa068c:35bcb74b
           Name : servername:0  (local to host servername)
  Creation Time : Thu Jun 28 14:38:32 2012
     Raid Level : raid0
   Raid Devices : 4

 Avail Dev Size : 1249999872 (596.05 GiB 640.00 GB)
    Data Offset : 2048 sectors
   Super Offset : 8 sectors
          State : clean
    Device UUID : e4947155:9ae45038:1c7135cb:a73e1e72

    Update Time : Thu Jun 28 14:38:32 2012
       Checksum : 121c770c - correct
         Events : 0

     Chunk Size : 256K

   Device Role : Active device 1
   Array State : AAAA ('A' == active, '.' == missing)


# mdadm --examine /dev/fioc
/dev/fioc:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x0
     Array UUID : d1b36e91:11335546:3afa068c:35bcb74b
           Name : servername:0  (local to host servername)
  Creation Time : Thu Jun 28 14:38:32 2012
     Raid Level : raid0
   Raid Devices : 4

 Avail Dev Size : 1249999872 (596.05 GiB 640.00 GB)
    Data Offset : 2048 sectors
   Super Offset : 8 sectors
          State : clean
    Device UUID : 664047e7:12cab443:9bec3b71:a205ce72

    Update Time : Thu Jun 28 14:38:32 2012
       Checksum : 560c4a81 - correct
         Events : 0

     Chunk Size : 256K

   Device Role : Active device 2
   Array State : AAAA ('A' == active, '.' == missing)


# mdadm --examine /dev/fiod
/dev/fiod:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x0
     Array UUID : d1b36e91:11335546:3afa068c:35bcb74b
           Name : servername:0  (local to host servername)
  Creation Time : Thu Jun 28 14:38:32 2012
     Raid Level : raid0
   Raid Devices : 4

 Avail Dev Size : 1249999872 (596.05 GiB 640.00 GB)
    Data Offset : 2048 sectors
   Super Offset : 8 sectors
          State : clean
    Device UUID : f77e67b2:6ef79bea:3b8471ea:da73403b

    Update Time : Thu Jun 28 14:38:32 2012
       Checksum : 9bbbc48 - correct
         Events : 0

     Chunk Size : 256K

   Device Role : Active device 3
   Array State : AAAA ('A' == active, '.' == missing)

"--examine"オプションは、デバイスのスーパーブロックを確認するオプション。

4本とも各デバイスのsuperblockの状態を確認したところ、特に問題なさそうなので、、、


# mdadm --assemble --scan /dev/md0
mdadm: /dev/md0 is already in use.

# mdadm --misc --detail /dev/md0
mdadm: cannot open /dev/md0: No such file or directory

# mdadm --assemble --scan /dev/md0
mdadm: /dev/md0 has been started with 4 drives.

結果論ではあるけど、こういう感じで修復した。

"/etc/mdadm.conf"からMDアレイを再構成しなおそうとしたんだけど、おそらく1〜2個目のコマンドで、/dev/md0 がstopしてしまったような挙動に思える。多分。confに構成を吐いてる分、素直にstopでもよかったかもしれない。

"mdadm --assemble --scan"を再実行したところ、正しい構成でRAIDデバイスが再構成された。


# echo "DEVICE /dev/fio*" > /etc/mdadm.conf'
# mdadm --detail --scan >> /etc/mdadm.conf'

一応、"/etc/mdadm.conf" は、こういう感じで作られていたっぽいことを補足。


# mdadm --detail /dev/md0
/dev/md0:
        Version : 1.2
  Creation Time : Thu Jun 28 14:38:32 2012
     Raid Level : raid0
     Array Size : 2499999744 (2384.19 GiB 2560.00 GB)
   Raid Devices : 4
  Total Devices : 4
    Persistence : Superblock is persistent

    Update Time : Thu Jun 28 14:38:32 2012
          State : clean
 Active Devices : 4
Working Devices : 4
 Failed Devices : 0
  Spare Devices : 0

     Chunk Size : 256K

           Name : servername:0  (local to host servername)
           UUID : d1b36e91:11335546:3afa068c:35bcb74b
         Events : 0

    Number   Major   Minor   RaidDevice State
       0     252        0        0      active sync   /dev/fioa
       1     252       16        1      active sync   /dev/fiob
       2     252       32        2      active sync   /dev/fioc
       3     252       48        3      active sync   /dev/fiod

問題なく復旧! =͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́


あわせて読みたい


Red Hat(r) Certified Technician & Engineer

Red Hat(r) Certified Technician & Engineer

2014/12/18

Apacheの認証ユーザをLDAPとローカルファイルを共用しつつ、LDAPの条件式を設定したい場合


若手がハマっていたので、ビシッと解決した一緒にアレコレやってみたシリーズ。タイトルが長くなってしまったけど、メモっておく。

某所のApache + Subversionサーバで、LDAP認証&ローカルファイル認証を使っていたのですが、LDAPでさらに条件式を追加する必要があった模様。要件はLDAPで特定の"description"を持つユーザを認可したい、と。Apacheのバージョンは2.2系。


アカンかった例

どれどれと見てみたら、下記の様に設定してありました。

<Location /svn>
     DAV svn
     SVNParentPath /data/svn/repos
     SVNListParentPath On

     AuthType Basic
     AuthName "Subversion Server (LDAP)"
     AuthBasicProvider ldap file
     AuthBasicAuthoritative Off
     AuthzLDAPAuthoritative Off

     AuthLDAPUrl ldap://ldap-server/ou=hoge,dc=fuga,dc=example,dc=com?uid
     Require ldap-attribute description=subversion

     AuthUserFile /etc/httpd/conf/localuser.list
     Require valid-user

     <Limit GET OPTIONS PROPFIND REPORT MERGE>
         satisfy any
     </Limit>
</Location>

LDAPでダメだったら、ローカルファイルの認証に移るような感じにしたいんだけど、これだとRequireディレクティブが複数あって、ローカルユーザの方でもldap-attribute云々を見てしまいそうな気がしていて、うまく認証できてない気がする。


成功した例

ならば、AuthLDAPUrlディレクティブに条件を持たせようと思って、以下のように設定したところ、期待通りの挙動となりました。

<Location /svn>
     DAV svn
     SVNParentPath /data/svn/repos
     SVNListParentPath On

     AuthType Basic
     AuthName "Subversion Server (LDAP)"
     AuthBasicProvider ldap file
     AuthBasicAuthoritative Off
     AuthzLDAPAuthoritative Off
     AuthLDAPUrl ldap://ldap-server/ou=hoge,dc=fuga,dc=example,dc=com?uid??(&(description=subversion))

     AuthUserFile /etc/httpd/conf/localuser.list
     Require valid-user

     <Limit GET OPTIONS PROPFIND REPORT MERGE>
         satisfy any
     </Limit>
</Location>

めでたしめでたし! =͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́


参考


2014/12/15

「MySQL Casual Talks vol.7」に参加してきた&資料まとめ #mysqlcasual


寒くなってきて食べ物が美味しくなってきたので、MySQLガチュアルに参加してきました。いつものように発表資料をまとめておこうと思います。


尚、このイベントの過去の参加記録は以下。

僕の中で、Vol.5は本当は開催されていないんじゃないかと、今でも思っている。(開催に気付かなかっただけ...)


MySQL Fabric つらい (@yoku0825)


MySQL Fabricはとても簡単でカジュアルそうだった。

(デモ、マスタDB落とした後、5秒くらいで切り替わっていた。)


MySQL on EC2 でカジュアルに消耗している (@tatsuru)

※資料公開待ちー


大変カジュアルというかガチュアルな印象でした。おつかれさまでした。

  • MasterはENI
  • SlaveはHAProxy
  • Master候補でMHA
  • 海を越えてもだいたい動く
  • データはEBSに
  • オフピークにSlave減らす検証している
  • EBS障害時に気付けるモニタリングを
  • RDS見送り
    • FO時間長い、Slave追従
  • ELBはDNSベースなのでつらい。HAProxyで

Galera Clusterについて何か話したい (@mita2)

※資料公開待ちー


地雷職人募集中とのことです。

  • Yahoo!さん、Oracleが200DB、MySQLが300DBくらいある
    • Exadataと呼ばれる冷蔵庫みたいなやつも飼育されているとのこと(さすがやで)
  • Percona XtraDB Cluster
    • wsreplでノード間同期
    • メジャーなMySQL forkでサポートされている
    • ヨーロッパでは広く普及
    • Openstackのバックエンドで採用
    • マスター・スレーブと違って、どこに書いてもOK(Active/Active)
    • Writeのスケールが解決できない
    • SSTは常にあると意識
    • ノード間の競合回避は楽観的ロックを使用
    • DDL長洲と全ノードで該当テーブルがロックする(OSCは使えない)
    • クラスタレプリケーションもできる

MySQL 4.0で9年動き続けたサーバをリプレイスしてバージョンアップした話 (@hfm)


こちら、素晴らしい知見をまとめられた発表でした。

MySQL 4.0.25 ⇒ 5.0.96 へリプレースするまでの様々な戦いの軌跡・・・!聞いていて胸が熱くなりました。

9年動き続けるようなDBのレガシー対応は、一見地味ですが、意外とかなりの労力が必要になると思います。(僕も部分的に体験していますが、かなり大変)

当日、tweetもしましたが、こういう環境があり、かつ前向きに対応できるペパボ社は、エンジニアにとってはかなり魅力的な環境だなーと思いました。



ソーシャルゲームDBの危機回避 (@strsk)


彼は「すどうさん」ではなく「すとうさん」です。



Ruby(Rails)でカジュアルに Q4M を使える何かを作った話 (@ryopeko)


https://github.com/ryopeko/shinq


RubyからカジュアルにQ4Mを使えるよ!でもモダンすぎて4.2じゃないと使えないよ!(ガチ)



Continuous Restoreへの道 (@kakerukaeru)


お父さんみたいな気持ちで発表を聞いていました。

とりあえず彼は緊張すると、ビールをあけるペースが上がることと、関西弁になることと、"バァーン"を連発することがわかりました。

とりあえず、事前に掲げていた目標はギリ達成できていたと思う。おめでとうww




MySQL Failover with Consul vol.2 (@ijin)


発表中、MySQL...ではなく、ノートPCのフェイルオーバー問題が別でありましたが、、、MHAとConsulの組み合わせは試してみたいなーと思いました。(Masterに障害があったら、ConsulがDNSエンドポイントを書き換える感じ)



ISUCON4 予選問題でアプリケーションコードを変更せず、"my.cnf"に1行だけ足して予選通過ラインを突破するの術 (@kazeburo)


ISUCON芸人の方の資料。MySQL 5.5.40前提。

相変わらず勉強になる。カゼブロエモンはいつになったら量産販売されるのか・・・。


NVMFS 使ってみたとか 言っちゃって マジカジュアルな奴 (@kuwa_tw , @neofact)


MongoDB芸人の方、おつかれさまでした。

(パフォーマンスは遅くなるけど、データ容量は結構稼げるので、ヒストリログとかDWHとかにいかが?とのことでした)


N:1レプリケーションの進捗 (@do_aki)

※資料公開待ちー


MySQL Casual 風物詩その1。

残念ながら進捗ないwとのことで、Raspberry Piの話でした。消費電力2〜3Wはかなり魅力的なので欲しい!

Raspberry Pi Model B+ (Plus)

Raspberry Pi Model B+ (Plus)


MySQLとActiveRecordその後 (@kamipo)


MySQL Casual 風物詩その2。

ActiveRecordのメンテナが、みんなポスグレ派で、なかなかプルリクがマージされず困っているお話。

ここ最近MySQL向けパッチをいっぱいPRしたんですけど4.2.0には入れれなかったので、MySQL向けパッチを4.x向けにバックポートしたgemを作りました。

activerecord-mysql-awesome - ActiveRecordのMySQL向けパッチのバックポート集 - Qiita

awesome!!! とりあえず、まとめとしては「kamipoさんはすごい」



トリの話 (@rkajiyama)

※資料公開待ちー

  • Planet MySQL 知っていますか?
    • 日本語ページもあるのでブログ登録してほしいとのこと
    • 文字化けしている問題有
  • InnoDB Deep Talk #2 やるよー

あわせて読みたい


エキスパートのためのMySQL[運用+管理]トラブルシューティングガイド

エキスパートのためのMySQL[運用+管理]トラブルシューティングガイド

2014/12/05

複数のWebサーバでSSLセッションキャッシュを共有してSSL処理を高速化(Apache + mod_ssl + mod_socache_memcache)


HTTPS(SSL利用)サイトがSEO的に優遇されるトレンドで、世間的にもHTTPS接続でサイト運用するサービスが増えてきています。

これが、ハイトラフィックサイトになってくると、このフロントエンドでSSL処理させることが負荷的にもなかなか辛いのです。


で、Apache 2.3以降では、Shared Object Cache Providerとして、memcachedが選択できるようになっています。

この仕組みを利用して、Apacheとmemcachedを並べることで、各サーバでユーザのSSL Session Cacheを共有しながらHTTPSリクエストを負荷分散できる構成を作ってみました。


WebサーバでSSLオフロード

常時SSLを利用したWebサイトを運用するために、SSLアクセラレータといったアプライアンス製品だとか、ソフトウェアだとApacheやNginxのSSLモジュールを使うケースが大半だと思います。

で、HTTPSリクエストが秒間数千〜数万〜数十万みたいなオーダーになってくると、一般的には、高価なアプライアンス製品に頼らざるをえないケースが多そうですよね。ただ、これだとスケールさせていくのに、ものすごい費用がかかることになる。かといって、従来どおりのOSSのWebサーバを横に並べていくだけだと後述するパフォーマンスが気になる。


まぁ、お金で解決するのは普通の話なので、ここからは、高価なアプライアンス製品を使うのではなく、オープンソースソフトウェアなWebサーバやProxyにSSLオフロードし、多くのリクエストをうまく捌くようにするにはどうしていくのかという話をします。


SSLオフロードによる処理負荷

結局、SSLを使うことのデメリットは、それに伴う処理負荷の増大をどうしていくかという話に尽きます。もちろん、暗号化方式や強度の設定により、負荷量は大きく異なるわけですが、それなりのパワーが必要になることにかわりはない。

SSL暗号化の強度が高くなればなるほど、暗号化/復号の処理負荷も高くなるのだ。一般に、鍵長を1024ビットから2048ビットへ増やすと、CPUの使用率は4〜7倍増えるといわれている。さらに、全てのWebページにわたってこの暗号化/復号処理をするとなると、Webサーバに掛かる負荷は膨大になってしまう。

常時SSLの落とし穴、Webサーバ負荷増大を回避するには? − TechTargetジャパン ネットワーク

じゃあ、この処理負荷をどうするのかという話になるんだけど、おおまかな方針としては以下のリンク先にほとんど書かれてあるのですが、SSL処理をできるだけさせないような仕組みを入れるという戦略になると思う。


箇条書きしてみると、、、

  • SSLセッションキャッシュタイムアウトの設定を見直す
  • SSLセッションキャッシュを共有させる
  • CipherSuiteの設定を見直す
  • SSLセッションチケットを使う

あたりになるのですが、今回は2つ目のSSLセッションキャッシュの共有について焦点を絞ります。(SSL Session Ticketは比較的新しいクライアントでしか対応していないみたいなので、そのうち取り上げます)


SSLセッションキャッシュを共有するということ

SSL処理負荷の大部分は、セッションの生成部分と言われています。通信のダンプを取ってみても、確かにこのハンドシェイクに時間(コスト)がかかっていました。

SSLセッションの再利用を行った場合のベンチマーク結果を示す。

・・・・・省略・・・・・

非常に大きな効果があり、5倍〜22倍近く速くなっている。

http://wizardbible.org/45/45.txt

とある通り、私の方でも簡単な検証してみたが、SSLセッションをキャッシュする/しないで、ハンドシェイクにかかる時間は、3〜10倍くらいの差がありました。


ApacheやNginxなどのSSLモジュールには、こうしたSSLセッションを生成した後にキャッシュする機構がありますが、デフォルトの設定ではソフトウェアが稼動しているホストのメモリ上に保存されます。

しかし、その前提において、負荷分散のためにWebサーバを横にスケールアウトさせていくと、どうなるか・・・は想像できると思います。

f:id:rx7:20141204195015p:image

上の図でいうと、例えばユーザからのリクエストがサーバ1に割り振られると、そこでServer1からSSLセッションが生成され、サーバ1上にユーザのSSLセッションがキャッシュされるため、ユーザは次からサーバ1にアクセスするとSSLハンドシェイクといった重い部分の処理が省略され、レスポンス/レイテンシが高速になります。

ただし、L7レイヤで特別な処理をしない限り、ロードバランサは次に同一ユーザから来たアクセスをサーバ1に向けることを保障しません。つまりサーバ2にリクエストが向くと再びサーバ2においてSSLセッションが生成されます。バックエンドのサーバがN台ある場合、何度となくSSLセッション生成が必要となり、負荷分散のためにスケールアウトしているはずが、SSL処理を行うサーバの台数が多くなればなるほど、非常に非効率な状態であることがわかります。


なので、リクエストが増えていくに従ってスケールアウト戦略では、バックエンドのサーバが増大することになるはずなので、こうしたSSLセッションキャッシュを、共有できるような仕組みが必要となります。


Apache 2.4 + memcachedを使ってみる

前置きが随分と長くなりました&冒頭にも書きましたが、Apache 2.3以降では、こうしたSSLセッションキャッシュを格納するプロバイダとしてmemcachedが利用できるようになりました。memcachedは今や多くのサービスで使われているキャッシュストアで使い慣れている方も多いでしょう。


こういったものが必要となる局面は、ハイトラフィックな環境なので、Webサーバ&SSL終端となるApacheも、SSLセッションキャッシュストアとなるmemcachedも複数台共存するようなシーンを想定しています。(動作確認するだけであれば、何台も必要にはなりませんが。)

ということで試しに利用するには、サーバを準備して、Apache2.4系とmemcachedが必要となるので、インストールしてみましょう。


Apache 2.4系のインストール

公式のダウンロードページからダウンロードして、インストールしてください。(インストールの仕方は、インターネット上に多く公開されているので割愛)


尚、CentOSやRHEL向けには、先日RPMファイルの作成方法を書いたので、ご参考にどうぞ。


memcachedのインストール

こちらも公式のダウンロードページからどうぞ。(こちらも情報はたくさん公開されているので割愛)

ただ、多くのLinuxディストリビューションでパッケージが用意されているので、そちらを使うも良し、でしょう。

CentOSとかだと、下記のコマンドでインストールできるはず。

# yum -y install memcached

Apache2.4でSSLセッションキャッシュをmemcachedにつめる設定

とっても簡単。Apacheそのものとか、mod_sslとかの細かい設定の詳細は割愛しますが、Apacheの設定内("httpd.conf"や"extra/httpd-ssl.conf"など)で、、、

LoadModule socache_memcache_module lib64/httpd/modules/mod_socache_memcache.so

こんな感じで該当のモジュールを読み込んで、、、


SSLSessionCache memcache:192.168.0.201:11211,192.168.0.202:11211,192.168.0.203:11211

SSLSessionCacheディレクティブでこんな感じで指定します。memcachedのサーバが複数あるときはカンマ区切りで指定します。

設定が済んだら、Apache(httpd)プロセスを起動/再起動してください。ちょっと端折った説明になりましたが、設定はこれだけです。


あわせてmemcachedも起動してアクセスできる状態にしておいてください。コネクション数とかストアできるメモリ量とか、諸々必要に応じて設定しましょう。


SSLセッションキャッシュが共有されているかを確認する

下記で公開されているツール(rfc5077-client)を利用する事で、SSLセッションが再利用されているかどうかを確認することができます。


Various tools for testing RFC 5077
https://github.com/vincentbernat/rfc5077

インストール方法は、READMEにも書いてありますが、

# yum install openssl-devel gnutls-devel nss-devel libpcap-devel libev-devel nspr-devel pkgconfig
# git clone  https://github.com/vincentbernat/rfc5077.git
# cd ./rfc5077
# git submodule init
# git submodule update
# make

これでビルドできるはず。ビルドが完了したら、、、


$ ./rfc5077-client {IPアドレス}

こんな感じで実行してみます。ちなみに"-p"オプションでポート指定ができます。(デフォルトは443番ポート)


f:id:rx7:20141205121807p:image:w480

※クリックすると大きく表示されます。あと、後述しますが比較のために、ソースコードを書き換えてリクエスト回数をデフォルトの5回⇒10回にしています。


こういう感じの結果が出るはずです。

なんとなくわかると思いますが、SSLセッションキャッシュが共有されていると、最初の1回目でセッションが生成された後、2回目以降はSSLセッションが再利用されている(SSL Session IDがReuseされて、同一のものになっている)事が確認できます。


ちなみに、SSL Session Cacheをロードバランサ配下の各ホスト内で持つようにしている環境で実行してみると、以下のような結果になります。


f:id:rx7:20141205121806p:image:w480

この環境では、ロードバランサの配下に複数台のWebサーバがいますが、SSLセッションキャッシュが各サーバで共有されていないため、バックエンド側で同じWebサーバに接続しないと、SSLセッションが再利用されていないことがわかります。

ちなみに、このツールは、SSL Session Ticketの確認にも対応しているので、なかなか便利でございます。


あわせて、memcached-toolとかでmemcachedの中身も確認しておくと、参考になるかと思います。


本構成での耐障害性はどうか

気になるのはこの部分ですが、まずバックエンドにいるキャッシュストアのmemcachedを複数台構成にしておくことで、Apacheサイドでよしなに分散してくれます。

memcachedが1台落ちても、その分のキャッシュが消えるだけで、次回の生成時には振り分けなおしてくれるし、仮にmemcachedが全台ダウンしても、SSLハンドシェイクで失敗する、みたいなことはなくApacheは問題なく稼動していました。(SSLセッションキャッシュが共有できなくなるだけ)


これはおまけですが、L4ロードバランサのバックエンドに、Apache2.4 + mod_sslなサーバ8台とmemcachedなサーバ3台を置いてみて、そのうちの1台のmemcachedのキャッシュのヒット率を出したグラフが以下となります。


f:id:rx7:20141205120448p:image:w480

もともとはnginxのSSLモジュールで動いていたものを、Apache2.4へと切り替えたのですが、最初は8台中1台を切り替えて様子見、3日後に8台中4台入れて様子見、さらにその3日後に8台全て切り替えとやった結果、キャッシュのヒット率、つまりSSLセッションキャッシュを再利用できている状態の遷移が綺麗に確認できました!

上述していますが、SSLハンドシェイクのレイテンシも3〜10倍程度高速化されているし、なかなか良い感じです。


まとめ

今のところ、なかなか安定して動いていて良い感じです。マル。

それでは! =͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́


参考


マスタリングTCP/IP SSL/TLS編

マスタリングTCP/IP SSL/TLS編

2014/12/03

最近書いたChefのCookbook(all-in-one_haproxy, redis)を公開します


公開します、というかGitHubに置いていただけですがー。


all-in-one_haproxy

2台セットでのHA構成を想定したHAProxyサーバを作るためのChef Cookbookです。2台セット冗長化済のHAProxyサーバをさくっと作るために書きました。


基本的には、2台で以下機能が連携しあう形で稼動します。

  • rsync + lsyncdの稼働 (各種設定ファイルの同期)
  • keepalivedの稼働 (HAクラスタ構成の実現)
  • HAProxyの稼働 (LB/ReverseProxyソフトウェア・SSL対応)
  • iptables/ip6tablesの稼働 (接続元の限定)
  • Quaggaの稼働 (エッジルータ等との動的経路広報の実現)
  • snmpdの稼働 (各種メトリクスの取得)
  • swap領域の調整
  • その他kernelパラメータの調整
GitHub - namikawa/all-in-one_haproxy: All-In-One HAProxy Chef Cookbook

詳細についてはREADMEをご覧くださいませ。


redis

Redis / Redis Sentinel を同一サーバで稼働させるためのChef Cookbookです。


CentOS(RHEL)で↑を実現するだけのシンプルなCookbookが欲しくて書きました。

こちらも詳細はREADMEを・・・と書きたかったが、全然詳細に書いていなかった...Orz そのうち書きます。



Thanks!! 10,000,000views!!

というわけで、このエントリは、11月中旬頃に本ブログの累計PVが1000万PVに到達した記念に書きました。

いつもありがとうございます!これからもよろしくお願い致します。


それでは! =͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́


2014/12/02

Apache

Apache 2.4系のRPMファイルを作成する


最近すっかりブログを書く頻度が落ちてしまっているので、このブログで1人アドベントカレンダーをやろうとしてたら、早速12/1から欠損してしまう程度にはダメ人間の私でございます。こんにちは。


ということで、ライトなネタと言えばメモ整理ということで、3ヶ月以上前にやったことのhistoryを逃がすべくエントリに書いておく。タイトル通り、Apache 2.4系RPMファイルを作ったメモ。

ちなみに作った環境は CentOS 6.5 です。


ダウンロード&準備

Apache 2.4の最新版を公式のダウンロードページで確認しましょう。今日現在の最新バージョンは2.4.10です。


# wget http://ftp.jaist.ac.jp/pub/apache//httpd/httpd-2.4.10.tar.bz2

こんな感じでダウンロードしてきます。


# yum groupinstall -y "Development Tools"

ビルドするので、必要そうなものをまるっとインストールします。


httpd(Apache)をビルド

# rpmbuild -ta --clean --rmspec httpd-2.4.10.tar.bz2
error: Failed build dependencies:
	zlib-devel is needed by httpd-2.4.10-1.x86_64
	libselinux-devel is needed by httpd-2.4.10-1.x86_64
	libuuid-devel is needed by httpd-2.4.10-1.x86_64
	apr-devel >= 1.4.0 is needed by httpd-2.4.10-1.x86_64
	apr-util-devel >= 1.4.0 is needed by httpd-2.4.10-1.x86_64
	pcre-devel >= 5.0 is needed by httpd-2.4.10-1.x86_64
	openldap-devel is needed by httpd-2.4.10-1.x86_64
	lua-devel is needed by httpd-2.4.10-1.x86_64
	libxml2-devel is needed by httpd-2.4.10-1.x86_64
	distcache-devel is needed by httpd-2.4.10-1.x86_64
	openssl-devel is needed by httpd-2.4.10-1.x86_64

早速ビルドしてみると、色々と依存しているパッケージが足りないみたい。


足りないものをインストールしていく

# yum install -y zlib-devel libselinux-devel libuuid-devel pcre-devel openldap-devel lua-devel libxml2-devel openssl-devel

で、yumで入れられそうな依存パッケージはインストールして、、、


# rpm -Uvh http://195.220.108.108/linux/fedora/linux/development/rawhide/source/SRPMS/a/apr-1.5.1-3.fc22.src.rpm
# rpm -Uvh http://195.220.108.108/linux/fedora/linux/development/rawhide/source/SRPMS/a/apr-util-1.5.4-1.fc22.src.rpm
# rpm -Uvh http://195.220.108.108/linux/fedora-secondary/development/rawhide/source/SRPMS/distcache-1.4.5-23.src.rpm

無いものはRPMファイルを作るべく、src.rpmをダウンロードしてきます。ファイルは"Rpmfind"とかで探してきます。


# yum install -y lksctp-tools-devel postgresql-devel mysql-devel sqlite-devel unixODBC-devel nss-devel db4-devel expat-devel

面倒くさくなってきたので先に書いておきますが、この後、rpmbuildを実行しますが、その際に足りなかった依存パッケージを事前に入れておきますw


# rpmbuild -ba ~/rpmbuild/SPECS/apr.spec
# yum localinstall -y ~/rpmbuild/RPMS/x86_64/{apr-devel-1.5.1-3.el6.x86_64.rpm,apr-1.5.1-3.el6.x86_64.rpm}

aprをビルドして、作成されたaprやapr-develをインストール。


# rpmbuild -ba ~/rpmbuild/SPECS/apr-util.spec
# rpmbuild -ba ~/rpmbuild/SPECS/distcache.spec
# yum localinstall -y ~/rpmbuild/RPMS/x86_64/{apr-util-devel-1.5.4-1.el6.x86_64.rpm,apr-util-1.5.4-1.el6.x86_64.rpm,distcache-devel-1.4.5-23.x86_64.rpm,distcache-1.4.5-23.x86_64.rpm}

そしてapr-utilやdistcacheも同様に。


再度、httpdをビルド

# rpmbuild -ta --clean --rmspec httpd-2.4.10.tar.bz2

・・・・・省略・・・・・

Wrote: /root/rpmbuild/SRPMS/httpd-2.4.10-1.src.rpm
Wrote: /root/rpmbuild/RPMS/x86_64/httpd-2.4.10-1.x86_64.rpm
Wrote: /root/rpmbuild/RPMS/x86_64/httpd-devel-2.4.10-1.x86_64.rpm
Wrote: /root/rpmbuild/RPMS/x86_64/httpd-manual-2.4.10-1.x86_64.rpm
Wrote: /root/rpmbuild/RPMS/x86_64/httpd-tools-2.4.10-1.x86_64.rpm
Wrote: /root/rpmbuild/RPMS/x86_64/mod_authnz_ldap-2.4.10-1.x86_64.rpm
Wrote: /root/rpmbuild/RPMS/x86_64/mod_lua-2.4.10-1.x86_64.rpm
Wrote: /root/rpmbuild/RPMS/x86_64/mod_proxy_html-2.4.10-1.x86_64.rpm
Wrote: /root/rpmbuild/RPMS/x86_64/mod_socache_dc-2.4.10-1.x86_64.rpm
Wrote: /root/rpmbuild/RPMS/x86_64/mod_ssl-2.4.10-1.x86_64.rpm
Wrote: /root/rpmbuild/RPMS/x86_64/httpd-debuginfo-2.4.10-1.x86_64.rpm

・・・・・省略・・・・・

+ exit 0

こんな感じで、rpmbuildが通って、複数のRPMファイルが作成されるはずなので、


# yum localinstall -y ~/rpmbuild/RPMS/x86_64/{httpd-2.4.10-1.x86_64.rpm,httpd-tools-2.4.10-1.x86_64.rpm,mod_proxy_html-2.4.10-1.x86_64.rpm,mod_ssl-2.4.10-1.x86_64.rpm}

あとは、このように必要なRPMファイルをインストールしてやればOKでございます。

ちなみに、Apache 2.4系のネタはしばらく続きます。

それでは! =͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́


サーバ構築の実際がわかる Apache[実践]運用/管理 (Software Design plus)

サーバ構築の実際がわかる Apache[実践]運用/管理 (Software Design plus)


オススメ (一部は、最近読んでいる本とも言う)
Chef実践入門 ~コードによるインフラ構成の自動化 (WEB+DB PRESS plus) クラウド Amazon EC2/S3のすべて~実践者から学ぶ設計/構築/運用ノウハウ~ [Web開発者のための]大規模サービス技術入門 ―データ構造、メモリ、OS、DB、サーバ/インフラ (WEB+DB PRESS plusシリーズ) エキスパートのためのMySQL[運用+管理]トラブルシューティングガイド [24時間365日] サーバ/インフラを支える技術 ~スケーラビリティ、ハイパフォーマンス、省力運用 Linux-DB システム構築/運用入門 (DB Magazine SELECTION) キャパシティプランニング ― リソースを最大限に活かすサイト分析・予測・配置 スケーラブルWebサイト 実践ハイパフォーマンスMySQL 第3版 ウェブオペレーション ―サイト運用管理の実践テクニック (THEORY/IN/PRACTICE) SQLアンチパターン インターネットのカタチ―もろさが織り成す粘り強い世界― ハイパフォーマンス ブラウザネットワーキング ―ネットワークアプリケーションのためのパフォーマンス最適化 Linuxの教科書―ホントに読んでほしいroot入門講座 (IDGムックシリーズ)