技術めも » 2017

アーカイブ「2017年06月」

jettyでJVMの統計を取る

jettyサーバで、jmx経由でJMV統計を取る方法。

${jetty.base}/start.iniファイルの末尾に以下を追記する。

#
# Initialize module jmx-remote
#
--module=jmx-remote
## JMX Configuration
## Enable for an open port accessible by remote machines
jetty.jmxremote.rmihost=localhost
jetty.jmxremote.rmiport=1099

一応これで、rmiで1099ポートにポートにアクセスすると、

JVMのモニタリングができる。

以上

投稿日時：2017年06月24日 23:14 カテゴリー：java [コメントがあればどうぞ]

rabbitmqでの名前解決

rabbitmqでクラスターを組む際、

クラスターに参加するノードすべてが名前解決によって、

他ノードに接続する仕様となっている。

hostsファイルやdnsmasqなどの簡易DNSを立てるのが簡単ではあるが、

クラウド環境を使っていると、hostsファイルやresolve.confファイルなどが、

再起動等で書き換えられしまうケースもある。

そこで、独自に名前解決を行う必要があるのだが、

erlangの名前解決手法が意外にハマったので、

クラスターの構築手順と合わせて備忘録を残しておく。

[バージョン]

os：centos7.2

rabbitmq：3.6.10（rpmで入れた）

[前提]

各ノードの情報は以下の通り。

192.168.15.11（ホスト名はbroker01）
192.168.15.12（ホスト名はbroker02）
192.168.15.13（ホスト名はbroker03）

[クラスターの構築手順]

１．インストールしたら、とりあえずbroker01,02,03の全台で起動

# systemctl start rabbitmq

この時点では各ノードが個別に動いている状態である。

２．broker01,02,03に/etc/rabbitmq/hostsというファイルを以下内容で配備

192.168.15.11 broker01
192.168.15.12 broker02
192.168.15.13 broker03

３．brker01,02,03に/etc/rabbitmq/erl_inetrcというファイルを以下内容で配備

{hosts_file, "/etc/rabbitmq/hosts"}.
{lookup, [file,native]}.

４．broker01に/etc/rabbitmq/rabbitmq-env.confというファイルを以下内容で配備

export ERL_INETRC=/etc/rabbitmq/erl_inetrc

RABBITMQ_NODENAME=rabbit@broker01
# ↓の設定は、独自です。なければ、デフォルトが適用されます。
RABBITMQ_LOGS=/var/log/rabbitmq/rabbitmq.log
RABBITMQ_SASL_LOGS=/var/log/rabbitmq/rabbitmq-sasl.log
RABBITMQ_PID_FILE=/var/run/rabbitmq/rabbitmq.pid
RABBITMQ_NODE_IP_ADDRESS=0.0.0.0
RABBITMQ_NODE_PORT=5672
RABBITMQ_DIST_PORT=5675

５．broker02に/etc/rabbitmq/rabbitmq-env.confというファイルを以下内容で配備

export ERL_INETRC=/etc/rabbitmq/erl_inetrc

RABBITMQ_NODENAME=rabbit@broker02
# ↓の設定は、独自です。なければ、デフォルトが適用されます。
RABBITMQ_LOGS=/var/log/rabbitmq/rabbitmq.log
RABBITMQ_SASL_LOGS=/var/log/rabbitmq/rabbitmq-sasl.log
RABBITMQ_PID_FILE=/var/run/rabbitmq/rabbitmq.pid
RABBITMQ_NODE_IP_ADDRESS=0.0.0.0
RABBITMQ_NODE_PORT=5672
RABBITMQ_DIST_PORT=5675

６．broker03に/etc/rabbitmq/rabbitmq-env.confというファイルを以下内容で配備

export ERL_INETRC=/etc/rabbitmq/erl_inetrc

RABBITMQ_NODENAME=rabbit@broker03
# ↓の設定は、独自です。なければ、デフォルトが適用されます。
RABBITMQ_LOGS=/var/log/rabbitmq/rabbitmq.log
RABBITMQ_SASL_LOGS=/var/log/rabbitmq/rabbitmq-sasl.log
RABBITMQ_PID_FILE=/var/run/rabbitmq/rabbitmq.pid
RABBITMQ_NODE_IP_ADDRESS=0.0.0.0
RABBITMQ_NODE_PORT=5672
RABBITMQ_DIST_PORT=5675

７．broker01,02,03に/etc/rabbitmq/rabbitmq.configというファイルを以下内容で配備

[
  {rabbit,
    [
      {loopback_users, []},
      {tcp_listen_options,
        [
          {backlog, 1024},
          {nodelay, true},
          {exit_on_close, false}
        ]
      },
      {vm_memory_high_watermark, 0.4},
      {disk_free_limit, "2GB"},
      {cluster_partition_handling, pause_minority}
    ]
  },
  {rabbitmq_management,
    [
      {listener, [{port, 5676}]}
    ]
  }
].

上記はあくまで一例で、ノード分断の際の生き残り戦略として、小数をダウンさせるという設定にしてます。

８．broker01,02,03の/var/lib/rabbitmq/.erlang.cookieファイルの内容を同じにする。
ここで、同ファイルの所有者はrabbitmq:rabbitmqで、権限は0400とする。

上記状態で、全ノードを再起動することで、

クラスター状態が完成する。

あと、rabbitmq-server.serviceファイルはちょっと変更して以下のようにしている。

デフォルトだと、nofile,noprocあたりがなかったような気がする。。

[Unit]
Description=RabbitMQ broker
After=syslog.target network.target

[Service]
Type=notify
User=rabbitmq
Group=rabbitmq
WorkingDirectory=/var/lib/rabbitmq
ExecStart=/usr/sbin/rabbitmq-server
ExecStop=/usr/sbin/rabbitmqctl stop
NotifyAccess=all
TimeoutStartSec=3600
LimitNOFILE=65536
LimitNPROC=65536

[Install]
WantedBy=multi-user.target

公式のドキュメントにだいたい書いてある通りですが。。

気になるのは、hugepageとか、OSレベルのIOのスケジューリングとかかな。

あとは、負荷テストやるのみ。。

また、負荷テストやったら書こうと思います。

以上

投稿日時：2017年06月24日 22:50 カテゴリー：rabbitmq [コメントがあればどうぞ]

rabbitmqについて簡単に触れてみた

信頼性の高いメッセージキューを使って、

遅延処理を行うケースの重要性について最近考えるようになった。

そのため、AMQPとか調べていて、rabbitmqを使ってみようかと考えた。

とはいえ、rabbitmqはAMQP0.9をベースとしており、

AMQP1.0をベースにしていないなどの点において、

採用候補としては迷うところである。

ActiveMQとかの方がいいかもね、という考えもある。

AMQPではないが、kafkaなどもよさげではあるが、

簡単に調べて、rabbitmqが良さげな点としては、

貧弱サーバでもある程度動く（と思っている）
クラスター機能が単体で存在している

といったところでしょうか。

riakを検証しててなんとなくわかったのですが、

開発言語であるerlangはそれほど大きなメモリを使わず、

マルチコアの利用も上手な印象であったため、

他サーバへの相乗り等、縮小することも考えると、悪くないかなーといった具合で検証を進めるてみることにしたというわけです。

ActiveMQやkafkaだと、貧弱サーバで動かすのは厳しい感じがしてます。。

で、簡単ながら、検証してみたことろ、メッセージの信頼性の度合はプログラムに依存するような印象を持ってます。

rabbitmq本体に、キューのタイプなどを定義できるのかなーと思っていたが、

特段相違そのような設定などは見られなったため、

プログラムの書き手が信頼性の確保、処理の速度について理解しておく必要があるという点が、

中々やっかいでもある反面、融通も効きやすい感じである。

また、諸々検証したら続きを書いてみようと思う。

以上

投稿日時：2017年06月11日 23:37 カテゴリー：rabbitmq [コメントがあればどうぞ]

MariaDBでgaleraとsplider

以前の記事で、galeraの書き込み能力を向上させるために、

spiderと併用したらいいのではないかと記載した。

しかし、この二つの組み合わせるには、

xa transactions（二相コミット）をあきらめる必要がある。

そもそも、galera自体、xaには非対応であり、

また、xa transactionsはバイナリログに対して、クラッシュセーフではないようだ。

（MySQLのドキュメントには記述があったが、MariaDBには記載を見つけられなかった。。）

上記前提を踏まえたうえで、

galeraとspiderの共演を実現するためには、xaをあきらめることは必須だが、

そもそもの話として、実装上複数ノードのwriteを極小化しておく必要が十分にあると考えられる。

これまで、プログラム側では、begin,begin,commit,commitみたいな実装を平気でしていたが、

そもそもこれ自体が出来るだけ避ける必要のある実装であることを、

今回のgaleraとspiderの共演を実現するために調査していた過程で気づいた。。。

今更の話だが、commitは失敗しないだろうという気持ちがどこかにあり、commitの失敗をリカバリーすることが頭の中から抜けていたように思えて反省している。

とはいえ、とはいえ、spiderを挟むことで、

プログラムのシャーディング負担を軽減し、

さらにgaleraで高可用性を確保する組み合わせは、とても魅力的ではある。

どこかで、galeraとspiderを共演するために、必要な設定・注意事項等をまとめようと思う。

検証した結果の結論から先に書くと、spiderは受信したSQLを変化させて、バックに投げるため、

場合によっては、SQLの発行回数の増加や、参照取得行数の増加が発生する。

この変化パターンを正確につかんでおかないと、気づかないうちに高負荷をバックに与えてしまう可能性があるため、十分に注意したい。

どっかでこのあたりもまとめてみようと思う。

以上

投稿日時：2017年06月11日 23:07 カテゴリー：mariadb, mysql [コメントがあればどうぞ]