• AmazoneSESを使ってメール送信する(SMTPリレー)

    こんにちは。プラットフォームの小宮です。 ちょっと前にAmazoneSESを使ってSMTPリレーでメール送信の設定をしたのでその記録を公開させていただきます。 ※SDKでなくSMTPリレーのほうを試します。(SDKつかうにはサーバにruby入っていてruby使う必要があるため。) ★SESの申し込みをする SESのサービスダッシュボードに「RequestProductionAccess」というボタンがあるのでそれを押すと お問い合わせ画面が出てくるので、必要な内容を入力する (名前とサービスドメインとメールアドレスとメールの用途など) Request Production Access to Simple Email Service(お問い合わせ) 入力送信すると、 リクエストありがとう、1日も早く使えるように審査するからマニュアル読んでお待ちください と英文メッセージが出る。 申請の翌日SESのダッシュボードを確認したところ、以下の標記になっていた Your Amazon SES Sending Limits Sending Quota: send 10000 emails per 24 hour period Quota Used: 0% as of 2013-03-08 10:53 UTC+9 Max Send Rate: 5 emails/second 24時間に10000通まで送ることが可能 現在の使用率は0% 最大送信レートは秒間5通 送信元は以下と教えていただいた → 会員登録時「no_reply@hoge.
    ...
  • WordPressサイトを簡単に他国語化できるプラグイン

    図1: qTranslate プラグイン WordPressはGNUのGettextを取り入れて多言語対応しているものの、実際に1つのサイトで多国語化を実現しようとすると、色々と困難な問題に突き当たる。とある開発案件にて多国語化の要望があったので、色々と言語系のプラグインなどを調べていたところ、見つけたのが「qTranslate」プラグインだ。 このプラグイン、サイト全体の言語管理と各投稿毎(コンテンツ毎)の言語管理を一括で行えるという優れもののプラグインである。 図2: 管理パネルのメニュー 管理パネルのメニューにてプラグインで指定した複数の言語を切り替えられるようになる(図2参照)のは序の口で、サイトのフロントエンド側からも言語を切り替えられる(切り替えのUIは別途作る必要はあるが…)。切り替え方も、ブラウザの言語設定に応じて自動化したり、訪問者の手動切り替えや、URLパラメータによる一時的な切り替えなど、色々と選べる。 そして、極めつけが、それぞれ個別の投稿に対して別言語によるコンテンツを同時に投稿できる点が素晴らしい機能である。 サイトの多国語化対応に際して一番大きな障壁が、サイトのメニューやフッター、ボタンといった共用コンテンツは言語ファイルにて他国語化できても投稿等のコンテンツはそれぞれ個別に管理しなければならないという点だ。例えば、日本語でアップした投稿と英語でアップした投稿はそれぞれ個別のコンテンツであり、それらを同じ一つのコンテンツとして管理するためには別の仕組みが必要だった。投稿のUI的にも同時に複数言語の記事が書けないことがネックとなって、サイトの保守性や利便性に難があったのだが、このプラグインはそれらの問題を一挙に解決してくれるのだ。 ということで、モノは試しに、この記事を日本語と英語両方で投稿してみた。英語版を見てみる場合はこのリンクをクリックしてみて欲しい。 図3: プラグイン設定画面 「qTranslate」プラグインは2013年6月19日現在のバージョンが2.5.34であり、同梱されている日本語翻訳ファイルが古く、一部翻訳されない部分があったので、私の方で最新バージョンに合わせた翻訳を行ってみた。 ※ 下記でダウンロードできた .mo ファイルを qTranslate プラグインの lang フォルダ内に入れてやる(上書きする)ことで最新の翻訳が反映されます。 qTranslate プラグイン 日本語化ファイル MO形式:qtranslate-ja.mo (27KB) 動作確認:WordPress 3.5.1 / qTranslate 2.5.34
    ...
  • 裏セグメントからyumやwget等したい場合の設定

    裏セグメントのホスト(たとえばVPCのEIPついてないのとかDBやNASなど裏においときたいやつ) から名前解決とかメールとかyumとかwgetとか時刻同期とかメールしたい! という場合の設定についてざっくりまとめさせていただきます。 とりあえず2パターンあります。 NATする(AWSの場合NATインスタンスを使う)パターンと、 グローバル通信できる管理サーバにソフトウェアを入れて解決するパターン。 ★NATする(AWSの場合NATインスタンスを使う)パターン db側はInternetGatewayつけてなくてパブリックでなくローカルなルーティングな場合、 名前解決をはじめ外に出られないです。(※) NATインスタンスを作るのも勿体ないと、複数NICがついたwebをnat化しようとしたところ、 マルチインタフェースなインスタンスはNATの出口に出来ない模様でした。 (※)最近新しくとったアカウントはVPCオンリーになっていてそちらだとグローバルIPがどんどん勝手に振られるようです。。(EIPつけざるをえない仕様) NATインスタンス作成方法は以下URLから Amazon VPCトレーニング-NATインスタンスの作成方法 VPC詳細 -ほぼ週刊AWSマイスターシリーズ第7回- Amazon VPCでNATを使ってPublic SubnetとPrivate Subnetを分ける 一番上のスライドのとおりでnatインスタンスを作成可能。 ざっくりいうと、 VPCサブネットをつくり、 “ami-vpc-nat"AMIでNATインスタンスを作成し、 NATインスタンスの"Change Source/DestCheck"をDisableにし、 NATインスタンスにEIPをアソシエートし、 PublicSubnetのRouterTableにNATインスタンスのIDを追加し、 必要に応じてNATインスタンスのSecurityGroupを設定する そのほか、一般的なルータ化設定方法と同様に、 インスタンス作成後にiptablesでnatのルール設定が必要になる模様。 /sbin/iptables -t nat -A POSTROUTING -o eth0 -s 10.0.0.0/16 -j MASQUERADE service iptables save iptables --list -t nat 上記スライドのとおりNATインスタンスをデフォルトゲートウェイにするルーティング設定も必要 forwardingの設定も必要
    ...
  • muninのデータを引き継ぐ方法

    こんにちわ。 プラットフォーム担当の宮下です。 今回は、オープンソースのモニタリングツール「munin」でホスト名を変更した時に 今までのデータもそのまま移行する方法を説明します。 なお使用するmuninのバージョンは、1.4.5を使います。 1)RRDのデータを移す。 muninのグラフ描写を行っている「RRD tool」のデータを移行します。 [shell] # cd /var/lib/munin/DIR # rename test01 test01-old ./test01-* [/shell] 格納場所に移動して、ファイルを一括で変換してしまいます。 2)HTMLファイルを移す。 [shell] # cd /var/www/html/munin/DIR # mkdir test01-old # chown munin:munin test01-old # cp -pfR test01/* test01-old/ [/shell] 生成されているHTMLと画像ファイルをまとめて移動します。 移動先のディレクトリが既にある場合は、mkdirとchownは飛ばして下さい。 またOSによってはaliasで「cp -i」が入っているかも知れません。 その時は、バックスラッシュを使って一括移動をします。 [shell] # \cp -pfR test01/* test01-old/ [/shell] これで次の収集間隔から新しいホスト名でデータが更新されていきます。
    ...
  • mysqlパフォーマンス改善への道(その1、現状の確認)

    パワー不足のmysqlをチューニングしてみます。 こんばんわ。プラットフォーム担当の宮下です。 今回は、バックアップ兼集計用に稼働しているmysqlのレプリケーションンサーバの パフォーマンス改善していきたいと思います。 これまでにもいくつか対策はしてきましたが、まずは環境をおさらいします。 ◇稼働してる環境は、AWSのEC2でlargeインスタンスを使用しています。 サービスは、OpenPNEを使用したSNSのサービスとなります。対象のMysqlはバックアップとデータ集計が目的で稼働しています。 (本番サービスでは使用していません) ◇mysqlのバージョンはちょっと古くて「5.0.77」になっています。multiで起動させていていて この他に開発環境用のmysqlも稼働していたりします。 ちなみに今の遅延秒数は、「1512561 秒」でまだ増加中です。 ◇これまでに変更した点ですが、 「innodb_buffer_pool_size」を512Mから2028Mまで増加、 「innodb_flush_log_at_trx_commit」を2から0に変更、 (リカバリの精度よりもスループットを優先) 「key_buffer_size」を32Mから300Mに変更、 「query_cache_size = 0」にして無効化しました。 効果は、DISKのI/Oが半分くらい減りましたが、遅延解消とまではいってません。 ◇最後にmuninで取得しているデータを確認します。 遅延が日々増えています。たまに減る事もありますが要因は分かりません。 常にDISKのread I/Oが大量に発生しています。 原因ははっきりしていて、DBデータに画像や動画データが格納されている為となります。 buffer pool sizeでは収まり切らないデータサイズなので常にDISKのread/writeが発生しています。 またMyISAMとInnodbが混在していてリソースが効率的に利用出来ていない事や、 OpenPNEが「delete aaa filename LIKE ‘%bbb%’」というクエリを大量に発行している事 などが解決すべき課題がたくさんあります。 現状を整理した事で、次回からは一つずつ改善対策を実施していきたいと思います。
    ...
  • 瀕死の技術ブログを復旧した話

    こんにちわ。 今回は主に(当ブログの)mysqlデータベース復旧のお話になります。 担当のお方が 「waordpressだとinnodbよりmyisamのほうが早いらしいので、 変える前にinnodbのmy.cnfのパラメータいじくってベンチマークとろうとした」 ことをきっかけにDBのデータがぶっ壊れました。 mysql5.6ならmyisam使わなくても参照専用トランザクション使うよう改造できれば早いらしいよという話はおいといて。(5.5だし) DBデータが読めなくてwordpressの管理画面にログインできなくなってしまいました。 -————————————————– 130528 11:59:24 [ERROR] Missing system table mysql.proxies_priv; please run mysql_upgrade to create it 130528 11:59:24 [ERROR] Native table ‘performance_schema’.’events_waits_current’ has the wrong structure 130528 11:59:24 [ERROR] Native table ‘performance_schema’.’events_waits_history’ has the wrong structure 130528 11:59:24 [ERROR] Native table ‘performance_schema’.’events_waits_history_long’ has the wrong structure
    ...
  • AmazonEBSでraid0を組んだ時のパフォーマンス検証

    AmazonEBSでraid0を組んだ時のパフォーマンス検証 EBSを組むと早いはなしを検証したい testでマルチ、ラージなら結構こうかある説がある模様。 既存移行の方法も検討(バイナリログ等のディレクトリ分けるところからかと。) 公式のユーザガイド(EBSPerformance) EBS自体が冗長構成組まれているのでraid0でいいと思われる。 インスタンスディスク(ローカルディスク、エフェメラルディスク)を使ってRAID0 EBSでRAID0を組むことは、RAID10(ミラーのストライプ)と同等である Largeインスタンス以上であれば、1台よりも2台の方がディスクI/O性能が目に見えて上がりました エフェメラルディスク(stopすると消えるほうのディスク)でraid0したい場合の起動コマンド例 [shell] ec2-run-instances ami-e965ba80 –region us-east-1 –key id_rsa –group sg-a4866fcc –placement-group test –instance-type cc2.8xlarge -b “/dev/sdb=ephemeral0” - b “/dev/sdc=ephemeral1” -b “/dev/sdd=ephemeral2” “/dev/sdf=ephemeral3” [/shell] ・ラージでEBSディスクを2つ追加して起動してログインする [shell] # df -h Filesystem Size Used Avail Use% Mounted on /dev/xvde1 9.9G 867M 8.5G 10% / none 3.
    ...
  • IDCフロンティア セルフクラウド入門編

    IDCフロンティアのセルフクラウドでAPI環境を用意するまで ~その1~サーバを起動する 始めまして。プラットフォーム担当の宮下です。 かねてから利用している、「IDCフロンティア クラウドセルフタイプ」の利用方法について基本的な流れを案内していきたいと思います。 会社としてもう今回は、仮想マシンの起動までの簡単な流れを説明させて頂きます。 パブリッククラウドは各社で独自の管理コンソールがあって慣れるまではそれぞれにくせがあります。その辺についても今後触れていければと思います。 仮想マシン作成 作成したユーザ/パスワードでログインしたら、〔ホーム〕→〔ダッシュボード〕から〔仮想マシン作成〕で作成を開始します。 OSの選択 次に起動するOSを決めていきます。リストをスクロールすると標準で用意されたテンプレートがたくさん出てきますのでお目当てのOSタイプが見つかるまで頑張って探してみて下さい。 (特にOSの指定が無ければLATESTの中から選び、ミドルウェアが必要かどうかで決めれば良いと思います) 今回はAPIツールを使用する環境を作りたいのでLATESTのLAMP環境OSを選びます。 〔[LATEST] LAMP or LVS(keepalived) or HAProxy or API Access Tool or Scalr or Elecoma or Yahoo! Cloud Storage Access Tools〕 を〔選択〕します。 マシンスペックの選択 次にサーバのスペックを決めます。 これはどこのクラウドでも同じだと思います。必要な用途に応じて最適なマシンスペックを選びます。 今回は最小の〔XS〕(1CPU/メモリ0.5GB)を選択します。 追加DISKの選択 次に追加DISKの設定をを行います。 OSデータ以外にコンテンツやログといった大きな容量を使用する場合は、ココでDISKを増設しておきます。 あとで追加もできますので必要が無ければ追加無しで進めます。なお今回はAPIツール用なのでDISKの追加は行いません。 SSH鍵の設定 最後にSSH鍵を設定します。 始めての時はまだSSH鍵が登録されていないので新規にSSH鍵を作成します。 生成された秘密鍵はSSH接続時やAPIツールを使用する際に必要となりますので大切に保管しておきます。 仮想マシン申し込み 登録した内容を最終確認して仮想マシン作成を開始します。 内容に差異が無ければ同意するにチェックして、〔申し込み〕を選ぶと作成が開始します。 最初の1台目の仮想マシンを作成する時には注意が必要です。赤字の注意事項に書かれている内容を確認しておきます。
    ...
  • MHAの動作確認と切替検証

    MHAの動作確認と切替検証 前回のつづきです。以下の図のように切り替わるようテストします。 ※本検証はマスタ1台、スレーブ2台、マネージャ1台構成。(多段構成は中間ノード障害時の復旧が猥雑になるので回避) スレーブにmanagerを同居させるとpurge_relay_logsとかぶると上手く切り替わらない可能性があるようです。 ※2台しかない場合で上手く切り替わらないことがあるようです。以下参考。 http://heartbeats.jp/hbblog/2013/05/mysql-mha-haproxy.html ⑥ 起動前チェック ・sshの動作チェック [shell] # masterha_check_ssh –conf=/etc/app1.cnf [/shell] OKな場合最終的に以下のように出力される [shell] Tue Oct 23 15:02:22 2012 - [info] All SSH connection tests passed successfully. [/shell] ・replicationの動作チェック [shell] # masterha_check_repl –conf=/etc/app1.cnf [/shell] OKな場合最終的に以下のように出力される(※mysql5.6からはMHAのバージョンによってはbinlog-checksum=NONEにしないとここで失敗するかもしれません) [shell] MySQL Replication Health is OK. [/shell] ※失敗するパターン レプリケーションのフィルタリングルールが合っていない LVSとMHAマネージャが相乗りの場合、チェックタイミングが重複しホスト毎DBサーバに拒否されてしまう(要flush hosts;) ⑦更新VIP用IFファイルを確認 db01/db02
    ...
  • MHA(MasterHighAvailabilityManager)の導入設定

    MHA(MasterHighAvailabilityManager)の導入設定 使用バージョン:mha4mysql-manager-0.53-0、MySQL-5.5 ①簡単な利点などの解説 MHAとはmysqlのマスタ障害時に最新のスレーブをマスタとして他のスレーブの差分を補完しマスタの向き先を変えてくれるプロダクト。 Heartbeat+mon+mysqlに比べるとreplicationの再構成も行ってくれるので切り替わってもDBがシングルにならないのが利点。(3台以上の構成の場合) 作者のスライド 公式サイト MHAの制約:mysql5.0以上、SBR(ステートメントベースレプリケーション)の場合LOAD DATA INFILEを使えない ※マネージャはadminサーバ、ノードはDBサーバ(マスタ・スレーブ共通) ② マネージャにてインストール ※以下、admサーバから実施 ・インストール [php] wget http://mysql-master-ha.googlecode.com/files/mha4mysql-node-0.53-0.noarch.rpm wget http://mysql-master-ha.googlecode.com/files/mha4mysql-manager-0.53-0.noarch.rpm yum –enablerepo=rpmforge install \ perl-Config-Tiny \ perl-Time-HiRes \ perl-Log-Dispatch \ perl-Parallel-ForkManager \ perl-Params-Validate yum install perl-DBD-MySQL rpm -ivh mha4mysql* [/php] 入ってなかったら [shell]yum install –enablerepo=remi mysql mysql-server perl-DBD-MySQL[/shell] ※マネージャはmysql-serverいらないかも ③ ノードにてインストール ※以下、dbサーバから実施
    ...
  • DEVLABはNginx環境に移行しました

    2013年3月末週、DEVLABサイトの環境移管を人知れず行ってました。 今週の4/2頃まではDEVLABにアクセスした人の中には、サイトが表示されなかったり、不具合が起きていた人もいたかもしれませんが、それらはすべて環境移管に伴う余波としてご理解いただけますと幸いです。まぁ、DEVLABの存在意義と運営方針の一つとして、「インターネットに関わる技術の研究開発のためには恐れずに何でもやってみよう!」というコンセプトを持っているので、今後もISAO社のDEVLABに関わるエンジニアの「好奇心の趣くままに」「衝動的に」「たとえサイトが壊れるとしても」色々とやって行くので、もしサイト来た時に変な動きをしていても ―― お、今何かやっているのかな?――と、温かく見守っていただきたいです(単なるバグの可能性もありますが、それも含みで)。 そんなこんなで、DEVLABの環境を今までのApache環境から今流行りのNginx環境に移管した次第。 さらに、noSQLデータベースの「MongoDB」やNode.jsもインストールして、今後は「リアルタイムWEBアプリケーション」の開発もできるように整備したのですが、これはISAO社のエンジニア向けの環境整備なので、DEVLAB側には今のところ影響はないかと。 さて、巷では「Nginx+リバースプロクシ+WordPress」の構成でWordPressのサイトパフォーマンスが劇的に向上すると云われているので、早速本DEVLABでもその施策を実施してみました。 結果、1ページ単位での表示レスポンス(レイテンシー)は特に変化はなかった(単ページ単位だと、逆にレスポンスはApacheの方が勝ってました…が、体感速度的には変わらなかった)のだが、Jmeterで負荷テストしてみたら、多数の同時リクエストが発生した際のNginxのレスポンスはかなり驚異的な向上が見られた次第。 実際にDEVLABのTOPページのリクエストレスポンスを比較したら、Nginx環境ではApacheの約23倍ほどもレスポンスが向上しました。 いやぁ、Nginxスゴイ!という感想でした。 ま、DEVLABは常時負荷が高まるほどアクセスされないので、今のところNginx環境も宝の持ち腐れ的な感があるんですけどね…。
    ...
  • Contact Form 7 でエラー時用画面にリダイレクトする方法

    Contact Form 7では、管理画面の、各フォームごとの編集画面の「その他の設定」に、 on_sent_ok: "window.location.href = 'リダイレクト先のURL';" と入力すれば、Contact Form 7 の処理終了後に、設定したURLにリダイレクトしてくれます。 しかし、この設定をすると、成功しても失敗しても同じURLに遷移するため、送信が成功したか失敗したかわかりません。 画面遷移ではなく、メッセージの表示をさせる場合では、成功時と失敗時でメッセージが切り替えられており、その処理にはJavaScriptを使っているはずです。 そこで、Contact Form 7 のjsファイルを改変して、エラー時にエラー時用のリダイレクトURLへ遷移させることにします。 /pm_webform/wp-content/plugins/contact-form-7/includes/js scripts.js 67行目付近の以下の行 } else { の下に以下の行を追加すると、失敗時用のリダイレクトURLへ遷移できます。 window.location.href = "失敗時用リダイレクトURL"; 同様に、57行目付近の以下の行 } else if (1 == data.mailSent) { の下に以下の行を追加すると、成功時用のリダイレクトURLへ遷移できます。 window.location.href = "成功時用リダイレクトURL";
    ...
  • Contact Form DB でチェック処理

    Contact Form DB でテーブルへの insert を行う前に、何らかのチェック処理を入れたい場合、フックを使います。 function my_form_chk( $cf7 ) { // 入力フォームの値取得 foreach ($cf7->posted_data as $posted_name => $posted_value) { // 元の値は変えないため別変数へ $posted_name_2 = $posted_name; $posted_value_2 = $posted_value; // 値の整形 $posted_nameClean = stripslashes($posted_name_2); $posted_value_2 = is_array($posted_value_2) ? implode($posted_value_2, ', ') : $posted_value_2; $posted_valueClean = stripslashes($posted_value_2); // それぞれの変数に代入 if( $posted_nameClean == 'a' ) { $input_param_a = $posted_valueClean; } if( $posted_nameClean == 'b' ) { $input_param_b = $posted_valueClean; } if( $posted_nameClean == 'c' ) { $input_param_c = $posted_valueClean; } } // チェック処理 if ( $input_param_a !
    ...
  • Contact Form DB のテーブルについて

    Contact Form 7 というアンケートフォームのプラグインは、メールを送信するだけなので、DBへデータを格納するようにするプラグインが Contact Form DB です。 両プラグインをWordPressに入れることで、手軽に入力フォームの内容をDBに格納できます。 しかし、この Contact Form DB で作られるテーブルが曲者でした。 WordPressの管理画面から Contact Form DB の管理画面を表示すると、入力フォームから入力されたデータの一覧を表示でき、それを見るとあたかも一つのフォームからの投稿が一つのレコードとして格納されているように見えます。 しかし、実際のテーブルには、入力フォームの input 一つ一つがそれぞれ1レコードとして登録されます。 入力項目が3つのフォームだと、1回の投稿で3つレコードが登録されるわけで、それぞれのレコードには、それぞれの入力項目の内容のみが、投稿時間と入力フォーム名と入力項目名をキーに記録されるのです。 ちなみにテーブル構造は下記の通り。 mysql> DESC wp_cf7dbplugin_submits; +-------------+---------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +-------------+---------------+------+-----+---------+-------+ | submit_time | decimal(16,4) | NO | MUL | NULL | | | form_name | varchar(127) | YES | MUL | NULL | | | field_name | varchar(127) | YES | MUL | NULL | | | field_value | longtext | YES | | NULL | | | field_order | int(11) | YES | | NULL | | | file | longblob | YES | | NULL | | +-------------+---------------+------+-----+---------+-------+ 6 rows in set (0.
    ...