MySQL から Amazon Aurora のリードレプリカを作成して移行してみた | はったりエンジニアの備忘録
RDS for MySQL から Amazon Aurora への移行を検討していたら、タイミングよく便利な機能がリリースされました。 New - Create an Amazon Aurora Read Replica from an RDS MySQL DB Instance いま稼働している MySQL から Aurora のリードレプリカを作成し、そのリードレプリカを昇格させることで簡単に MySQL から Aurora へ移行できるという機能です。 これまでも MySQL のスナップショットから Aurora クラスタを起動することはできましたが、今回のリードレプリカを使えば移行時のダウンタイムを最小化できます。 リードレプリカの作成と昇格 対象となる MySQL を選択して "Create Aurora Read Replica" をクリックするだけ。拍子抜けするくらい簡単です
Golang で AWS の請求額を取得するコマンドを書いた
数年前までインフラ界隈の OSS は Ruby で開発されることが多かったと思いますが、最近は Golang がメインストリームになりつつあります。有名どころでは HashiCorp や Docker が採用していますし、個人で開発されている Hugo や STNS も Golang で書かれています。 この流れを受けて、必然的に Golang のソースコードを読む機会が増えてきました。ただ、バグを見つけて Pull request を送ろうと思っても、Golang が書けないので Issue を上げることしかできなかったことがあります。 プログラミング言語が壁になって OSS に貢献できないのはエンジニアとして悔しいので、連休中に勉強を兼ねてちょっとしたコマンドを Golang で書いてみました。 freee ではサービスの品質を落とさずに、インフラコストをいかに抑えるかが課題のひとつに
Lambda を使って CloudWatch Logs から S3 へ自動的にエクスポートする
Lambda のログは自動的に CloudWatch Logs に保存されますが、他と連携する場合は S3 のほうが何かと都合がいいです。 CloudWatch Logs にはログデータを一括で Amazon S3 にエクスポートする機能があります。リアルタイム性が求められずバッチ処理で定期的にエクスポートする用途に向いています（リアルタイム性が求められる場合は、サブスクリプションを使用したログデータのリアルタイム処理が用意されています）。 というわけで Lambda と CloudWatch Events を使って、CloudWatch Logs から S3 へ自動的にエクスポートしてみます。 CloudWatch Logs API の CreateExportTask S3 へのエクスポートは CloudWatch Logs API の CreateExportTask を使います。
Lambda を使って SSL サーバ証明書の有効期限をチェックする | はったりエンジニアの備忘録
SSL サーバ証明書の更新は何かと忘れがちで、大手サイトでもたまに有効期限切れで事故ったりしています。常時 SSL/TLS が当たり前となった現在では、機会損失だけでなく信用も失いかねません。 ドメイン認証 (DV) 証明書であれば更新作業のいらない AWS Certificate Manager が使えるのですが、EV SSL 証明書だとそういうわけにもいきません。 更新を忘れないために Zabbix などの監視ソフトウェアでチェックしている人が多いと思いますが、サーバを立てずにもっと手軽に導入できる方法として今回は Lambda を使ってみました。監視ソフトウェアと比べてサーバの運用が不要で、かつ 0 円で構築できるというメリットがあります。 openssl コマンドで証明書の有効期限を取得する 証明書の有効期限を取得するには openssl コマンドを使うのが手っ取り早いです。 $
Ansible Vault 機能のソースコードを読んでみた | はったりエンジニアの備忘録
Ansible 1.5 から DB のパスワードや API の認証情報といった機密情報を暗号化する Vault 機能が提供されています。 あらかじめ設定したパスワードを使って機密ファイルを共通鍵認証で暗号化する機能ですが、そもそも Vault 機能を信じても大丈夫なのでしょうか？ 機密情報を任せるのであれば、どういった暗号アルゴリズムで処理されているのかちゃんと理解しておきたいものです。 というわけで、ansible-vault コマンドの実装を読んでみました。今回読んだのは 5/25 にリリースされた v2.1.0.0-1 です。 GitHub 上のソースコードへリンクを貼っているので、詳しく読みたい方は参考にしてください。 Ansible のソースコードを読み解く ansible-vault コマンドの実体は lib/ansible/cli/vault.py です。 lib/ansib
AWS の API を利用するときに気をつけたい 3 つのポイント | はったりエンジニアの備忘録
AWS の魅力は API を使ってインフラをコントロールできる点です。インフラだけでなく SQS や DynamoDB といったサービスも API で操作します。ほぼすべてのサービスに API が用意されているので、AWS を使いこなせば使いこなすほど API の利用頻度も上がります。 今回は AWS の API を利用するときに気をつけたいポイントをまとめてみました。 リトライ処理を入れる AWS に限ったことではありませんが、API リクエストはさまざまな理由で一時的に失敗する可能性があります。クライアント側のネットワークエラーの可能性もありますし、大量のリクエストを送ってサーバ側でスロットリングされているかもしれません。 なので、API リクエストは 一時的な失敗を前提 にリトライ処理を入れましょう（AWS SDK を利用しているのであればリトライ処理は自動的に行われます）。一度失敗
Amazon Route 53 にドメイン移管してセキュリティを高める | はったりエンジニアの備忘録
このブログのドメインをお名前.com から Amazon Route 53 に移管しました。 移管手順はクラスメソッドさんのブログが参考になります。自分の場合、約 6 時間で完了しました。 お名前.com から Amazon Route 53 へドメインを移管する Route 53 のドメイン料金は他社と比べて安いわけではありません（ドメイン登録は Gandi というレジストラを通じて行われます）。人気の gTLD (.com / .net / .org) が 10 〜 12 ドルなので、料金だけ見ればお名前.com の方が安いです。 ではなぜ移管したかと言うと、一番の理由はセキュリティです。 国内レジストラの残念な現状 控えめに言っても、国内レジストラはセキュリティに対して積極的に投資しているようには見えません。 多くの Web サービスが 2 段階認証に対応していく中、国内レジストラは
AWS 権限管理のベストプラクティスについて考えてみた | はったりエンジニアの備忘録
AWS は Management Console や API ですべて操作できます（Direct Connect など一部例外もあります）。データセンターの物理的なセキュリティなどは AWS が責任を負うところで、ユーザーはまったく意識する必要はありません。 その代わり、OS やミドルウェアの管理、アプリケーションの設計や実装、適切な権限管理などはユーザーが責任を負うところです。 今回はあまり取り上げられないけど、すごく大事な権限管理についてまとめてみました。自分が仕事で関わっているプロダクトで権限管理を見直すときに調べたことをベースにしていますが、もっと良いプラクティスがあればぜひ教えてください。 AWS アカウントは使わない 普段の運用で AWS アカウントは使いません。 AWS アカウントとは、最初にサインアップするときに作られるアカウントです。 このアカウントは Linux で言う
CDH の HBase データを Amazon EMR に移行する | はったりエンジニアの備忘録
Cloudera Hadoop (CDH) の HBase データを Amazon EMR に移行する検証をしているのですが、ベストプラクティスがわからず苦戦しました。 @kuborn さんにいろいろ教えてもらって、これで行けるだろうという手順が確立できたので公開します。 大まかな流れは、こんな感じです。 CDH の Master ノードで hbase コマンドを使ってデータをエクスポートする。 HDFS 上のファイルを Linux のファイルシステムにコピーする。 2 番のファイルを EMR の Master ノードに転送する。 Linux 上のファイルを HDFS のファイルシステムにコピーする。 HBase シェルでテーブルを作成する。 hbase コマンドを使ってデータをインポートする。 データのエクスポート hbase コマンドを使って、テーブル単位でエクスポートします。 hog
EC2 メンテナンスで慌てないための 4 つの設計ポイント | はったりエンジニアの備忘録
公式ブログでもアナウンスがありましたが、月末にかけて EC2 のメンテナンスが行われます。 EC2 メンテナンスアップデートに関して EC2 のメンテナンスには、ゲスト OS を再起動するインスタンスリブートと、ホストの物理サーバを再起動するシステムリブートの 2 つがあります。どちらのメンテナンスが予定されているかは EC2 Management Console の Events ページで確認できます。詳しいことは Amazon EC2 のメンテナンスのヘルプページに書いてあります。 今回は Xen のセキュリティ対応ということでシステムリブートが必要になりますが、どちらのメンテナンスでもユーザーの都合に合わせて事前に実施することができます。 インスタンスリブート: ゲスト OS にログインして再起動させるか、EC2 Management Console で Reboot を選択 システ
CloudTrail のログを Kibana で可視化して改善のヒントを探す | はったりエンジニアの備忘録
7 月から東京リージョンでも使えるようになった CloudTrail（一部のサービスはまだ未対応）。 API 呼び出しのすべてが記録されるのでセキュリティ監査の証跡ログとして利用されることが多いと思います。 オンプレミスで同じことをやろうとするとコストも労力も馬鹿になりませんが、CloudTrail ならポチッと有効にするだけです。素晴らしいですね！ セキュリティ監査の証跡ログだけではもったいないので、他の活用方法を考えてみました。 CloudTrail のログをどう活用するか CloudTrail のログには AWS CLI / SDK からのリクエストはもちろんのこと、Management Console の操作も記録されています。 Management Console も裏側で API を叩いているからです。 API を使って構築や運用の自動化を進めると Management Con
運用してわかった Amazon RDS のパフォーマンスを上げる 3 つのコツ
本番環境で RDS を運用して数ヶ月。いろいろ試して RDS のパフォーマンスを上げるコツがわかってきたのでまとめたいと思います。 ここで取り上げるコツは以下を前提にしています。 データベースは PostgreSQL (Multi-AZ 配置) Read よりも Write が多い 夜間のバッチ処理がピーク 1 レコードは小さいが、一度に書き込むレコード数は多い アプリケーションの特性によっては当てはまらないこともあるでしょうし、他の RDBMS では結果が違ってくると思います。そこを踏まえたうえで参考にしてください。 Availability Zone はどちらかに寄せる RDS の Multi-AZ は耐障害性を上げるために欠かせない機能で、本番環境では Multi-AZ 配置が推奨されています。 Multi-AZ 配置にすると物理的に独立した AZ (Availability Zon
CloudWatch のカスタムメトリクスで JVM の GC を監視する | はったりエンジニアの備忘録
JVM 上で動くアプリケーションを運用するには GC に気を配る必要があります。 GC をうまくチューニングするためには、まずは現状を知ることが大切です。 GC の統計情報は jstat -gcutil で取得することができます。試しに Jenkins のプロセスを見てみます。 $ pid=`sudo jps | grep jenkins | awk '{ print $1 }'` $ sudo jstat -gcutil ${pid} S0 S1 E O P YGC YGCT FGC FGCT GCT 0.00 57.68 21.33 66.26 99.51 73 0.179 4 0.271 0.450 この統計情報を定期的に取得してビジュアライズすれば GC の傾向がつかめます。この AWS 全盛期に昔ながらの RRDtool は使いたくないので、今回は CloudWatch でビジュ
オンプレミスから AWS に移行して変えた 3 つのこと
7 月に開催された「JAWS-UG 三都物語 2014」でも発表したとおり、自分が関わっているプロダクトをオンプレミスから AWS に移行しました。 JAWS-UG 三都物語 2014 に登壇しました 移行して 2 ヶ月ほど経ちましたが、目立った障害もなく安定した運用を続けています。スライドでも少し触れていますが、これまでのやり方を大きく変えるキッカケにもなりました。 今回は「オンプレミスから AWS に移行して変えた 3 つのこと」と題して、社外に公開できる範囲でご紹介します。 稼働中のサーバに変更は加えない いわゆる Immutable Infrastructure の考え方を取り入れました。最初は流行りに乗りたかったという気持ちが大きかったのですが、今では昔のやり方にはもう戻れません。 オンプレミスでは本番稼働中のサーバにログインして何か変更するということが当たり前に行われていました
CentOS 6.5 に Elasticsearch をインストールする | はったりエンジニアの備忘録
CentOS 6.5 に Elasticsearch をインストールする機会があったので、忘れないようにメモしておきます。特別なことはしてなくて、ほぼドキュメントのままです。 OS とミドルウェアのバージョンは以下のとおり。 CentOS 6.5 (x86_64) OpenJDK 1.7.0_51 Elasticsearch 0.90.11 OpenJDK のインストール Elasticsearch は Java で書かれているので、まず JDK をインストールします。今回は OpenJDK を使いましたが、Oracle Java でも大丈夫です。 # yum install java-1.7.0-openjdk # java -version java version "1.7.0_51" OpenJDK Runtime Environment (rhel-2.4.4.1.el6_5-x
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
