Embulk+Digdagを利用して、個人情報を考慮したマスク処理を開発用DBに行う — みんなのウェディングエンジニアリングブログ
みんなのウェディングのインフラエンジニア横山です。 今回は開発用DBのマスク処理にEmbulk+Digdagを利用し始めた話について書きます。 開発用DBのマスク処理とは 弊社では、週次で本番DBのスナップショットから開発環境用DBを作り直しています。 これにより、常に本番環境と同じテーブル定義、データ量で開発を行うことができ、以下のようなメリットがあります。 本番にデプロイする前に、開発、ステージング環境で不具合を早期発見できる 実際に近いデータで、本番を想定した確認ができる ここで問題になってくるのが、ユーザの氏名やメールアドレスといった個人情報の扱いについてです。 開発用DBは本番DBのスナップショットから作成されているため、開発用DBにも本番DBの個人情報が入ってしまっています。 この状態で利用すると、以下にあげる問題が考えられます。 開発中の機能による、ユーザへのメール誤配信など
Circle CIをPerformance Planに移行したらテスト時間が半分になって最高だった — みんなのウェディングエンジニアリングブログ
みんなのウェディングのインフラエンジニア横山です。 今回は、Circle CIをPerformance Planに移行したところ、テスト時間が半減して最高だった件について書きます。 みんなのウェディングのCI/CD環境について Performance Planへの移行前は、みんなのウェディングのCI/CD環境は以下のような構成でした。 ポイントはマスターマージの際にAWS Codeシリーズを利用して、テスト&ステージング環境へのデプロイを行っている点です。 以前は、マスターマージ後のテスト&ステージングデプロイもCircle CIで行っていました。 しかし、Circle CIではトピックブランチのテストも行われているので、マスターマージ後のテスト&ステージングデプロイがそちらと同じCI待ち行列に入ってしまうという問題がありました。 これによりトピックブランチのテストが多いとステージングデプ
みんなのウェディングのデータ分析基盤の現状 — みんなのウェディングエンジニアリングブログ
こんにちは、みんなのウェディングの小室 (id:hogelog) です。 今回はみんなのウェディングにおけるデータ分析基盤の現状についてご報告させていただきます。 三行まとめ 忙しい人のために先に結論を書くと bricolage と embulk で Redshift に集めて re:dash で分析 です。 データ収集 データ収集は bricolage のジョブネット機構を用いて bricolage の各種ジョブや embulk を連携させ、Redshift にデータを取り込んでいます。 参考までに https://github.com/hogelog/dwh-example に簡単な構成例を準備しました。 MySQL → Redshift みんなのウェディング http://www.mwed.jp/ のデータベースとしては MySQL を利用しています。 MySQL から Redshi
みんなのウェディングの継続的デリバリー — みんなのウェディングエンジニアリングブログ
みんなのウェディングの高井です。今回は、みんなのウェディングで構築している継続的デリバリーの仕組みについての話です。 継続的デリバリーとは？ インターネットサービスを提供していくうえで、とても重要なプラクティスのひとつに「継続的デリバリー」があります。継続的デリバリーとは、ソフトウェアをいつでもリリース可能な状態にしたままで構築していくというソフトウェア開発の規律です。 継続的デリバリーを採用することで、ソフトウェアのリリースサイクルを短かくすることができるようになります。リリースサイクルを短かくすることは、サービスの仮説検証プロセスを短かくすることにつながります。 サービス開発の本質は、どこにあるのか分からないユーザーのニーズをとらえることにあります。ですから、仮説検証の機会を最大化できる継続的デリバリーはサービス開発にとって、欠かせないプラクティスとなるわけです。 完了条件を定義する
クラス設計の原則 — みんなのウェディングエンジニアリングブログ
みんなのウェディングの高井です。 クラスベースのオブジェクト指向プログラミング言語を利用している人であれば、クラスとは、ありふれていて普段から利用するものです。にもかかわらず、良いクラスをつくるというのは、なかなかに難しいことです。 先日、みんなのウェディングでアルバイトをしてくれている学生さんのコードレビューをしていたときにも、それを強く感じました。 実践的プラグマティックには「ソフトウェアの規模や文脈にあわせて、適切に抽象化していただきたい」という以上のことを言っても仕方がないところなのですが、それだけでは経験の浅いプログラマーにとって、まったく分からないという話になってしまいます。 というわけで、今回はクラス設計の原則についてのお話しです。 Bertrand Meyerのクラス設計の原則 Bertrand Meyerは『オブジェクト指向入門 第2版』の中で、クラス設計について章をひと
みんなのウェディングはAWSで動いています — みんなのウェディングエンジニアリングブログ
みんなのウェディングの高井です。当社でもエンジニアブログを始めることになりました。よろしくお願いします。 AWSへと移行しました 私たちのサービスは、先月の2015年9月29日早朝にAmazon Web Services（AWS）へと移行しました。 AWSへ移行することによって、ユーザーのみなさんに、より素早く、より安定したサービスをお届けできるようになるというのが総合的な判断理由になります。そして、その背景にはいくつかの技術的なメリットやコスト的なメリット、そしてその他に忘れてはいけないメリットがあると考えています。 技術的メリット まず、AWSに移行することで、柔軟にサーバー資源を確保したり、構成することが容易になるというのが挙げられます。 以前の環境では、料金体系や納期の関係で、簡単にサーバーの追加や廃止ができる状況ではありませんでした。なので、一台のサーバーが複数の役割を担っている
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
