カテゴリーアーカイブ インフラ

takahashi 著者:takahashi

さくらのクラウド GSLBで常に1つのIPアドレスだけ返すようにする方法

さくらのクラウドで利用できるロードバランサの一つに、GSLBというものがあります。

これはトラフィックを裏側のインスタンスなどに再分配するのではなく、インターネットと直接接続された(グローバルIPを持っている)複数のインスタンスに割り当てられたIPを返却してクライアントにランダムなインスタンスへアクセスさせるIPアドレスベースのロードバランサです。

さくらのクラウド上では通常のトラフィック分配を行うロードバランサと比較して安価で、仕組みもシンプルでわかりやすく、そしてリージョンにまたがって運用することができる点はメリットです。

さてこのさくらのクラウドのGSLBですが、デフォルトの設定のままで複数インスタンスを登録すると、

;; ANSWER SECTION:
lbtest.example.com. 29 IN CNAME  site-XXXXXXXXXXXX.gslb3.sakura.ne.jp.
site-XXXXXXXXXXXX.gslb3.sakura.ne.jp. 9 IN A    1台目のサーバーIP
site-XXXXXXXXXXXX.gslb3.sakura.ne.jp. 9 IN A    2台目のサーバーIP

さくらのクラウドのDNSサーバーからは上記のように、登録したインスタンスの全IPアドレスが 一度に 返されてしまいます。

この場合、どのインスタンスへつなげに行くのかの挙動がクライアント側任せになってしまい、クライアント側の実装によってはどちらかの特定の インスタンス につなげ続ける”偏り”が発生してしまう可能性があります。

負荷をなるべく均等に分配したい場合は、これでは困ってしまいます。

このGSLB機能には、実は詳細設定があり、各インスタンスのIPの出力比率を偏らせることができます。

通常、重みをつけて運用してしまうと、IPの出力が非均等になってしまいますが、すべてのインスタンスの重みの値を同一にしておけば、均等の確率でいずれかのインスタンスのIPが出力されます。

GSLBの設定画面の右上のメニューから”監視・応答方法の変更”をクリックします。

すると下記のような画面が出てきます。

赤枠で囲った”重み付け応答を”有効”に変更します。

この状態でもう一度DNSの設定値を確認してみると

;; ANSWER SECTION:
lbtest.example.com. 21 IN CNAME  site-XXXXXXXXXXXX.gslb3.sakura.ne.jp.
site-XXXXXXXXXXXX.gslb3.sakura.ne.jp. 1 IN A    サーバー1のIP
;; ANSWER SECTION:
lbtest.example.com. 29 IN CNAME  site-XXXXXXXXXXXX.gslb3.sakura.ne.jp.
site-XXXXXXXXXXXX.gslb3.sakura.ne.jp. 1 IN A    サーバー2のIP

このようにインスタンスのいずれか1つのIPのみ応答されるようになります。

これなら余分なIPアドレスが同時に配信されることがないので、より均等にアクセスを振り分けることができそうです。

なお、一部のChrone系などのWebブラウザでは、DNSサーバーで設定されているTTL(キャッシュの有効期限)よりも長くDNSの値を保持しようとするようなので、注意が必要です。

  • この記事いいね! (0)
takahashi 著者:takahashi

さくらのクラウドで停止させたくないインスタンスを停止時に自動で再起動させる方法

さくらのクラウド上の仮想サーバーにおいて、何かの拍子にシャットダウンしてしまったり、といったトラブルは、実稼働中のサーバーインスタンスでは避けたいものです。

ただ、何か問題が発生してシャットダウンしてしまった場合、止まってしまったOS自身からはもちろん制御することができないため、外部から何らかの操作を行わない限りは自動で復旧できません。

さくらのクラウドには”タグ”という、各リソースにタグ付けをしてグループ分けをする機能があります。

実はこのタグ機能に、@から始まる特定のタグを入れておくと、単に分類だけではなく、特定の動作をさせることができるような仕組みがあります。

例えば、今回のようにサーバーを停止させたくない場合は

@auto-reboot

というタグを追加しておくと、ダッシュボードから操作を行わない限りインスタンスが電源off状態になっても自動的に再起動されます。

ちょっと隠し機能感満載の仕組みですが、別で監視用のインスタンスやサービスなどを利用することなく再起動してくれるのはありがたいですね。

自動再起動以外にもいくつかオプションがあるようですので、さくらのクラウドでサーバーを動かしている方はぜひ確認してみてください。

特殊タグ一覧 – さくらのクラウド ドキュメント

  • この記事いいね! (0)
takahashi 著者:takahashi

Certbotで証明書の更新後に自動で特定の処理をさせる方法

無料でSSL証明書を発行してもらえるサービスであるLet’s Encryptですが、同時に更新とSSL証明書の設定の自動化を行うCertbotという仕組みを提供しているのも特徴です。

このCertbotですが、いくつかプラグインがあり、ワイルドカード(任意のサブドメインに適用できる)SSL証明書を取得しない場合、メインで使用しているWebサーバー向けのCertbotプラグインを使用すると、自分の方で細工しなくても、Webサーバーを停止することなく自動で取得時の認証や証明書の適用を行ってくれます。

ただ、ワイルドカード証明書の場合はDNS-01という、ドメインを登録しているDNSサーバーを使用した認証方法に限定されてしまうため、上記のようなWebサーバー向けのプラグインを使用することができません。

この場合、ワイルドカード証明書を取得時、もしくは更新時にSSL証明書のインストールや差し替えは行われますが、Webサーバーへの自動適用は行われません。

この状態のままだと、せっかくSSL証明書を自動で更新できても、自動でWebサーバーに読み込まれないため、”いつの間にか期限切れになってた…”なんて状況が発生してしまうことになります。

そこで、僕の場合はSSL更新時に合わせてWebサーバーを自動的に再起動できるように、スクリプトを次のようにしていました。

/usr/bin/certbot renew --force-renew >> /var/log/letsencrypt/ssl-renew.log 2>&1 && service webサーバーのサービス名 restart >> /var/log/letsencrypt/ssl-renew.log 2>&1

ただこの方法では、まれにSSL更新とWebサーバーの再起動のタイミングが悪く、Webサーバーの再起動が失敗してしまうことがありました。

SSL更新からWebサーバー再起動の間で数秒間マージンを置くことで一応はちゃんと動作するようになったのですが、あくまで固定した秒数待つだけで、SSLの更新状態のチェックなどは行っていないため、必ずしも対策できているとはいいがたい状況でした。

さてどうやればうまくできるかなーと考えていたところ、実はCertbot自体に、処理完了後に特定のコマンドを実行させることができる機能があることを知りました。

例えば、証明書取得時のコマンドに

sudo certbot certonly --manual \
-d example.com -d *.example.com -d ...  \
-m mail@example.com \
--agree-tos \
--manual-public-ip-logging-ok \
--preferred-challenges dns-01 \
--server https://acme-v02.api.letsencrypt.org/directory

のようにするかと思いますが、このコマンドに

--post-hook="実行したいコマンド"

のようなオプションを付加することで、SSL取得処理終了後に指定したコマンドを実行してくれます。

例えば、証明書取得終了後にnginxを再起動させたい場合は

sudo certbot certonly --manual \
-d example.com -d *.example.com -d ...  \
-m mail@example.com \
--agree-tos \
--manual-public-ip-logging-ok \
--preferred-challenges dns-01 \
--server https://acme-v02.api.letsencrypt.org/directory
--post-hook="service nginx restart"

のようにすると、SSL取得処理が終了した時点でnginxを再起動させることができます。

取得時に指定したオプションはcertbotの設定ファイルに記録されるため、2回目以降の更新時では

sudo certbot renew

とするだけでpost-hookも含めて処理してくれるようになります。

なお、このpost-hookはssl証明書の処理が完了したら、失敗・成功にかかわらず実行する、という指定になってますが、処理前に実行させたり、証明書更新が行われた後のみ実行、といった指定も可能となっているようです。

Let’s EncryptのSSL証明書更新時にサービスを再起動する – Qiita

このあたりの設定をうまく使えば、運用がより楽になりそうですね。

  • この記事いいね! (0)
takahashi 著者:takahashi

CentOS 7 のApache 2.4でmpmを切り替える方法

Apacheには、mpmと呼ばれる動作モードがあります。

最近のApacheでは、デフォルトで”prefork”が指定されているかと思います。

このモードでは、1アクセスごとに1つのApacheプロセスを立ち上げ、ブラウザからサイトへの要求にこたえます。

この方式では、アクセスが増えれば増えるほどApacheのプロセスが増えていくため、大量のアクセスが来るとOSの負荷が増えてしまい、サーバー全体の動作が重くなってしまいます。

一方、MPM動作モードには workerとeventとよばれるものもあります。

これらのモードを使用すると、使用されるプロセス数を節約することができるため、サーバー全体への負荷を少なくすることができます。

ただし、ノンスレッドセーフなモジュールを使用している場合などはそのモジュールは使用できなくなるとのことで、注意が必要です。

さて、このMPMの切り替えですが、OSによっては設定ファイルが分散化されていることがあります。

CentOS 7 の場合は

/etc/httpd/conf.modules.d/00-mpm.conf

にMPMの切り替えが行える記述があるので、ここを変更します。

# Select the MPM module which should be used by uncommenting exactly
# one of the following LoadModule lines:

# prefork MPM: Implements a non-threaded, pre-forking web server
# See: http://httpd.apache.org/docs/2.4/mod/prefork.html
LoadModule mpm_prefork_module modules/mod_mpm_prefork.so

# worker MPM: Multi-Processing Module implementing a hybrid
# multi-threaded multi-process web server
# See: http://httpd.apache.org/docs/2.4/mod/worker.html
#
#LoadModule mpm_worker_module modules/mod_mpm_worker.so

# event MPM: A variant of the worker MPM with the goal of consuming
# threads only for connections with active processing
# See: http://httpd.apache.org/docs/2.4/mod/event.html
#
#LoadModule mpm_event_module modules/mod_mpm_event.so


内容としては非常に親切で、コメントアウトの付け替え後、Apacheを再起動するだけでMPMの切り替えを行うことができます。

上記の例では、6行目のmpm_prefork(Preforkモード)が有効になっています。

例えば、もしworkerモードを有効にしたい場合は、12行目の

#LoadModule mpm_worker_module modules/mod_mpm_worker.so

の先頭のコメントアウト(#)を外し、先程の6行目の

LoadModule mpm_prefork_module modules/mod_mpm_prefork.so

の先頭に#をつければOKです。

# Select the MPM module which should be used by uncommenting exactly
# one of the following LoadModule lines:

# prefork MPM: Implements a non-threaded, pre-forking web server
# See: http://httpd.apache.org/docs/2.4/mod/prefork.html
#LoadModule mpm_prefork_module modules/mod_mpm_prefork.so

# worker MPM: Multi-Processing Module implementing a hybrid
# multi-threaded multi-process web server
# See: http://httpd.apache.org/docs/2.4/mod/worker.html
#
LoadModule mpm_worker_module modules/mod_mpm_worker.so

# event MPM: A variant of the worker MPM with the goal of consuming
# threads only for connections with active processing
# See: http://httpd.apache.org/docs/2.4/mod/event.html
#
#LoadModule mpm_event_module modules/mod_mpm_event.so


この状態で

sudo apachectl configtest #設定が間違っていないかチェック
sudo systemctl restart httpd #Apache再起動

とすればMPMを切り替えることができます。

・変更前

$ sudo apachectl -V
...
Server version: Apache/2.4.6 (CentOS)
Server built:   Aug  8 2019 11:41:18
Server's Module Magic Number: 20120211:24
Server loaded:  APR 1.4.8, APR-UTIL 1.5.2
Compiled using: APR 1.4.8, APR-UTIL 1.5.2
Architecture:   64-bit
Server MPM:     prefork
  threaded:     yes (fixed thread count)
    forked:     yes (variable process count)
...

・変更後

$ sudo apachectl -V
...
Server version: Apache/2.4.6 (CentOS)
Server built:   Aug  8 2019 11:41:18
Server's Module Magic Number: 20120211:24
Server loaded:  APR 1.4.8, APR-UTIL 1.5.2
Compiled using: APR 1.4.8, APR-UTIL 1.5.2
Architecture:   64-bit
Server MPM:     worker
  threaded:     yes (fixed thread count)
    forked:     yes (variable process count)
...

Server MPMの部分が切り替わっていることが確認できるかと思います。

素のApacheの場合は元の設定ファイルであるhttpd.confに統合されていたりするので、あらかじめわかりやすく別ファイルに準備されているのはありがたいですね。

  • この記事いいね! (0)
takahashi 著者:takahashi

Redisの用途

最近ふと興味がわいて、NoSQLのことを調べてたりします。

NoSQL(Not only SQL)とはMySQLやPostgreSQLのような従来のRDBとは異なるデータの持ち方の概念(データモデル)でデータを管理するデータベースシステムのことです。

なぜわざわざRDBとは違うシステムが必要になるのかというと、RDBだけではうまく対応できないような場面や、RDBでない方が都合がよいケースが存在するためです。

例えば、有名なMastodonはNoSQLの一つであるRedisをプロセス間のデータ共有に使用していますが、これをもしRDBで置き換えたなら、おそらくリアルタイムに次々とデータが投稿されるMastodonでは追い付かなくなるでしょう。

Redisならインメモリにデータが保持されているので、このあたりの処理がRDBと比較して高速化できます。(ただし、NoSQLにはデータの整合性や、RDBのような複雑な条件での検索などが弱いため、この部分は逆にRDBで補うことになります。)

そんなRedisですが、具体的にどんな場合で利用すると効果的なのか、ちょっと調べてみました。

・複雑なデータを保持するキャッシュストレージとして使う

例えばWebsocketを使ったシステムをNode.jsとApache+PHPの組み合わせで構築した場合、Node.jsとApache(PHP)は別の環境で動作しているため、そのままではデータの共有ができません。

そこで、同じデータを参照できるようにするために、データの橋渡し役が必要になります。

RDBやファイルといった選択肢もありますが、ここにRedisを使うことで、高速かつある程度複雑な構造のデータも簡単に扱うことができるようです。

・キャッシュしたデータを(半)永久的に保持したい

RedisはMemcachedとよく比較されますが、Memcachedは再起動すれば値が消失してしまうのに対し、RedisはファイルとしてDBのデータを保持しておく仕組みもあるため、設定をしておけばRedisサービスやサーバーの再起動を行ってもデータを保持しておくことができます。

・Pub/Subを使った仕組みを実装したい。

メッセージのやり取りをする仕組みのモデルとして”Pub/Sub”というものがあるのですが、Redisではこのモデルにのっとった仕組みを標準で提供してくれるようです。

Pub/Subモデルを使用したシステムを作りたい場合は、最適な選択肢になるかもしれません。

このように、システムによっては従来にない便利な仕組みを提供してくれるRedisですが、注意しなければならないのはRedisが”インメモリDB”であるという点です。

メモリ(RAM)上ででデータの保持を行う仕組みのため、メモリの容量の限界を超えたデータの保存は行うことができません。(記事によってはRAM全容量の約半分以上は保存できない、という話も記載されています。)

そのため、万が一容量がいっぱいになってしまった場合は、書き込み失敗とするか、古いデータを削除する以外に方法がありません。

データを永続させられるとは言え、Redisに置いておく必要のなくなったデータは積極的に削除するか、完全に永続化が可能なRDBやファイルなどに移しておくなどの工夫が必要となりそうです。

実際のところ、RedisはRDBを置き換えるのではなく、DBとアプリケーションの間に+αで追加することで、より高速な動作を可能にする使い方に最も効果がありそうです。

調べていてかなり興味がわいてきたので、是非一度Redisを使ったシステムも作ってみたいですね。

参考記事:
RedisとElastiCacheを分かりやすくまとめてみた – Qiita

Redisのメモリ検証 – Qiita

  • この記事いいね! (0)
takahashi 著者:takahashi

さくらのクラウドにサードパーティサービスとの連携が追加

ふとさくらのクラウドのダッシュボードを見たところ、

マーケットプレイスなる項目が増えていました…!

どうやら、外部のベンダーが提供するサービスと連携ができるようになったようです。

しかも特典がついているサービスも。

マーケットプレイス – さくらのクラウド

さくらのクラウドはシンプルで、完全時間課金制というとても素晴らしいサービスですが、ほかのクラウドサービス同様サードパーティのサービスとも連携できるようになったということで、さらに強力なインフラが簡単に利用できるようになったようです。

かつて地震による停電が発生した際も丸2日ほど自家発電のみで耐え抜くという偉業を成し遂げたことのあるさくさのクラウド。
今後もっと盛り上がって、ほかのクラウドサービスに匹敵するレベルまでいくのでしょうか。

今後の動きが楽しみですね。

  • この記事いいね! (0)
takahashi 著者:takahashi

Postfixでメールサーバー間暗号化を有効化する方法

メールソフトの送信サーバー設定で、SSLやSTARTTLSなどでメールソフトとサーバー間の通信を暗号化できることはご存知の方も多いかと思います。

実は、メールソフト⇔サーバー間だけでなく、サーバー同士の暗号化も行えることはご存知でしょうか。

これをやっておかないと、折角メールソフトからサーバーまでの間が暗号化できていても、自分側のメールサーバーから送付先のメールサーバーまでの間が平文になってしまい、だれでも覗ける状態になってしまいます…

今回はPostfixでのサーバー間暗号化通信を有効化する方法をご紹介します。

postfixの設定ファイル

sudo vi /etc/postfix/main.cf

に次の一行を追記します。

smtp_tls_security_level = may 

これだけでOKです。
あとはメールサーバーを再起動すれば適用されます。

この指定を行っておくことで、相手のメールサーバーがTLS通信に対応しているときに自動で暗号化接続を行ってくれます。

ちなみに

smtp_tls_security_level = encrypt

という指定もありますが、このようにしてしまうとTLSに対応していないメールサーバーとは通信できなくなってしまうので注意してください。

設定自体は超簡単なので、自分でSMTPサーバーを持っている方は是非設定してみてください。

Postfixのメールサーバ間通信でTLSを有効にする – Qiita

  • この記事いいね! (0)
takahashi 著者:takahashi

Apacheでは1つのpemファイルに中間証明書をまとめてあっても別で中間証明書を指定する必要がある件

最近新しいサーバーをセットアップし、その上でApacheをセットアップし、新しいサイトを構築しました。

そのサイトへはPCやスマホのWebブラウザからは問題なく閲覧できていたのですが、何故かアプリのWebviewからアクセスできないという問題が発生していることが判明。

具体的には、Webview側でサイトへアクセスしようとするとステータスが”Cancelled”になる、というもの。

いろいろ調べたところ、どうやら平文では問題なく閲覧できてはいるものの、SSL(https)経由になると何故か正常に見ることができないことがわかりました。

そこで、SSL通信のチェックサービスを使って、SSLの状態を調べてみました。

SSLチェック【証明書・プロトコル・暗号スイート確認】 – cman

結果、証明書の認証チェーンに問題があることがわかりました。

ApacheではSSLの証明書の指定を行う際、下記のように書きます。

SSLCertificateFile /etc/letsencrypt/live/example.jp/fullchain.pem
SSLCertificateChainFile /etc/letsencrypt/live/example.jp/chain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/example.jp/privkey.pem

今回構築したサーバーではSSL証明書にLet’s Encryptを使用しており、Apacheに入れる設定としては上記のようになります。

fullchain.pemについては1ファイルに証明書本体と中間証明書も含まれているのですが、Apacheではそのようには認識してくれず、中間証明書は別で指定する必要があります。

その中間証明書の指定が2行目の SSLCertificateChainFile の記述になります。

今回の場合、2行目のSSLCertificateChainFile が抜けていたことで証明書のチェーンが壊れてしまっていたのが原因だったのですが、PCやスマホのブラウザで見るとOSがチェーンを補完して問題なく見れてしまうため、アプリでつなげようとしてようやくエラーに気付いた形でした。

SSLを使うサイトを立ち上げた際は、ブラウザでのチェックだけでなく、ご紹介したSSLチェックツールなどでもテストしておいた方が確実かもしれません。

  • この記事いいね! (0)
takahashi 著者:takahashi

確かにSIMフリーのAndroid端末でも防災速報が受信できた話

先日の大雨は久々に不安を感じるレベルでした。

側溝から水が噴水のようにあふれていたり、道路に水が冠水してしまっていたり、極めつけは普段名前の聞かないような川の周辺まで警報が出て、ちょっと恐怖を感じました。

冠水こそありましたが、川の氾濫という最悪の自体がギリギリ回避できて、ほっとしました。

ところで、先日SIMフリーのAndroid端末でも、Android8.1から標準で緊急速報が受信できるようになったという話をご紹介しました。

こちらの記事ではIIJ社が行った実験による緊急速報の受信の様子をご紹介しましたが、実際に今回の増水による避難勧告発令時に、自分が所有するPixel 3a(Android 9)でも実際に緊急速報を受信することができました。

実際にはこのような画面になりました。

前回ご紹介したIIJ社の実験の通り、最初に内容のない緊急速報を受信し、そのすぐ後に詳細な内容を受信しました。

以前使っていたXperia Z5(Softbank版 Android 6)では警報を受信しても専用の通知音がなるだけでしたが、Pixel 3aの場合は通知音が流れた後、内蔵の読み上げエンジンで全文が音声で読み上げられるようになっていました。

これはロック画面を解除していない状態でも行われ、スマホを開くことなく警報内容を確認することができるので、安心できます。

この機能はAndroid 8.1以降のAndroidには標準で含まれているため、SIMフリーであってもモバイル回線に接続されていればメーカーやキャリア側で意図的に無効化されない限りは8.1以降のすべてのAndroidで受信できそうです。

いままで、こういった重要な機能が搭載されていないといった理由でSIMフリー版のスマホを購入がちょっと心配になるパターンもあったのですが、今後はそういった縛りを受けることなく機種を選ぶことができそうなのはとてもありがたいですね。

  • この記事いいね! (0)
takahashi 著者:takahashi

突然MyDNS+Let’s Encryptでの証明書取得が不能に。原因はIPv6経由のアクセス。

たまたま自宅のサーバーのSSL証明を確認したら、Let’sEncryptで取得しているSSL証明書の有効期限が1か月を切っていました。

1か月に1回強制更新するように設定してあったのでおかしいなぁと思いつつ調べたところ、どういうわけか自宅サーバーからDNSサーバーへの接続がうまく行かなくなっていました。

自宅のサーバーではLet’s Encryptからワイルドカード証明書を取得しており、その際ドメインを管理しているDDNSのMyDNSと連動させることで自動で取得できるようにしています。
(詳細はこちらの記事をご覧ください。)

サーバーが接続しているインターネット回線はIPv6に対応しているため、SSL証明書を取得する際の接続先としてスクリプトで指定している”www.mydns.jp”への接続もIPv6で接続されるのですが、何故かMyDNSのIPv6アドレスに通信が到達できない状態になっていたのが原因でした。

他にもMyDNSに限らずサーバーからあらゆるドメインへのIPv6アドレス経由での接続ができなくなっているようだったので、どうやら自宅側のIPv6ネットワークがおかしくなってしまっているようでした。

とりあえず、接続先の指定をipv4.mydns.jpに変更してIPv4に固定したところ、問題なく通信できるようになったので、当分はこれでしのげそうです。

何故突然IPv6での接続ができなくなってしまったのかはまだ分かっていないのですが、まだまだ不安定なところがあるのかもしれませんね…

  • この記事いいね! (1)