サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
Wikipedia
blog.mwed.info
Amazon EKS Advent Calendar 2019 22日目の記事です。 ますます寒さ厳しくなる中、みなさまいかがお過ごしでしょうか。 みんなのウェディングのインフラエンジニア横山です。 Docker/kubernetes流行ってますね。弊社でもみんなのウェディングの実行基盤のEKS移行を進めてまいりました。 最終的には全てのコンポーネントをEKS上に移行したいですが、最大の難所であるアプリケーションサーバの移行が完了したので、移行を考えた理由、移行への道のりについてまとめます。 なぜ移行するのか? そもそも、なぜDocker/kubernetesは流行っているのでしょうか? それはそれぞれ以下のようなメリットがあるためと言われています。 Docker 環境の可搬性、再現性が高く開発効率が上がる 本番、ステージング、開発で同一のイメージを利用することで環境ごとの差異を気にせず開
みんなのウェディング、松久(@kamonegi1977)です。 独自で作っていたCSSフレームワーク「Esthe(エステ)」を置き換えているお話です。 CSS フレームワークを置き換える理由 2015年から利用していたCSSフレームワーク「Esthe(エステ)」の置き換えを進めている理由は、主に3つあります。 ☠️ 1.Railsの組み合わせで、不具合を発生させやすい input要素で radioボタンを作りチェックしたかどうかは、li要素の class に checked と指定する必要があります。 Rails では form helper によりradioボタンでは、checked 属性を処理してくれます。 しかし、Esthe 独自の class については、フォームのレイアウトに合わせて helper を開発したりすることがありました。 <ul class="radio"> <li
みんなのウェディングのインフラエンジニア横山です。 今回は、既存VPCを流用したEKS環境の構築に引き続き、SpinnakerをEKS上にデプロイする手法について書きます。 Spinnakerについて Spinnakerとは、Netflixが開発した継続的デリバリー(CD)を実現するためのツールです。 Spinnakerがどういったものかについては、この記事の主題ではないので詳しく説明致しません。 以下の公式ドキュメントを確認いただければと思います。 https://www.spinnaker.io/ 日本語情報ですと以下のメルカリさんの記事が大変参考になります。 https://tech.mercari.com/entry/2017/08/21/092743 今回、SpinnakerのEKS上へのデプロイを行うにあたり、ネット上にまとまった情報が少なく大変苦労しました。 私のような苦労を
みんなのウェディングのインフラエンジニア横山です。 今回は、既存VPCを流用したEKS環境の構築手法について書きます。 みんなのウェディングのEKS環境について みんなのウェディングでは現在、インフラ基盤のEKS移行を進めています。 EKS環境を作成する場合、通常は以下のようにeksctlやCloudFormationを利用します。 https://docs.aws.amazon.com/ja_jp/eks/latest/userguide/getting-started.html しかしながら、eksctlを使って構築した場合、今後リソースの内容を更新したいときにeksctlを使い続けることになります。 弊社ではインフラ構成管理に既にterraformを使っています。先々の運用を考えると、使うツールは必要最小限にしておきたいところです。 また、CloudFromtaionを使った場合、新
こんにちは。新卒UXデザイナーの小板(画像向かって右)です。 今回は、先日行われたRails Girls Tokyo 12thに参加してきたレポートをお届けします! Rails Girlsとは? プログラミング初学者の女性を対象にした、Railsの勉強会です。世界的に行われており、まずは「自分が作ったものが動く」という体験をすることが目的となっています。 カリキュラムは、ネットに公開されているRails Girls Guidesを参照しながら、みんなでわいわいプログラミングを楽しむという内容になっています。 今回は12回目の開催となるRails Girls Tokyoで、実際にRailsを使って仕事をしているコーチ陣に教えてもらいながら、herokuで成果を公開するところまで体験してきました!� きっかけ そもそも、UXデザイナーである私がどうしてRails Girlsに参加しようと思った
みんなのウェディングのインフラエンジニア横山です。 今回は、Circle CIをPerformance Planに移行したところ、テスト時間が半減して最高だった件について書きます。 みんなのウェディングのCI/CD環境について Performance Planへの移行前は、みんなのウェディングのCI/CD環境は以下のような構成でした。 ポイントはマスターマージの際にAWS Codeシリーズを利用して、テスト&ステージング環境へのデプロイを行っている点です。 以前は、マスターマージ後のテスト&ステージングデプロイもCircle CIで行っていました。 しかし、Circle CIではトピックブランチのテストも行われているので、マスターマージ後のテスト&ステージングデプロイがそちらと同じCI待ち行列に入ってしまうという問題がありました。 これによりトピックブランチのテストが多いとステージングデプ
みんなのウェディングのインフラエンジニア横山です。 今回は開発ブランチのデプロイにAWS Fargateを利用し始めた話について書きます。 開発ブランチデプロイとは、開発中のトピックブランチを社内のディレクターやデザイナーに確認してもらうために、開発サーバにデプロイすることを指します。 弊社では永らく以下の記事でお伝えしたように、単一サーバへの複数の開発ブランチデプロイを行なってきました。 開発ブランチをデプロイする 今回、こちらの手法を刷新して、デプロイ先としてFargateを利用するように変更しました。 これにより、以下のようなメリットがあります。 サーバのリソース制約から解放されるため、同時に何個でもデプロイできる。 ブランチ単位でタスクが起動するので、利用頻度に応じて柔軟に課金されるようになる。 どのように実現しているのか ここからは実際の仕組みについてお話しします。 まず、概略図
みんなのウェディングのインフラエンジニア横山です。 今回はAWSのサービスを利用したサーバーレスなデプロイボットの作り方についてお伝えします。 作成の動機 弊社には、rubotyで作られた、minaというデプロイ用のボットが存在しており、こちらのボットにSlack上で話しかけることで本番環境へのデプロイを行っていました。 今回は、このminaの置き換えとしてサーバーレスなデプロイボットが作れないか取り組みました。 作成の動機は以下の2点です。 ボットのメンテナンスコストの削減 ボットが稼働するサーバコストの削減 概要 全体の流れは以下の図の通りです。 まとめると、 Slackのスラッシュコマンドを実行 API Gatewayにリクエストが届く API Gatewayに紐づけられたLambdaでデプロイ処理が実行される デプロイされる ※AWS側のリソースはSAMで管理。 といった感じです。
みんなのウェディングのインフラエンジニア横山です。 今回はpuma利用時のメモリ管理と、計測の大切さについてお話ししたいと思います。 何が起きたか 始まりは今年の1月1日、元旦でした。 インフラエンジニアの携帯に1通のアラートが届きました。それは、appサーバのAvailable Memory低下を表すものでした。 その当時のグラフを以下に貼ります。 原因がすぐにはわからなかったため、緊急対応としてappサーバの再起動を行ったところ、Available Memoryの値は回復しました。 原因究明 1月4日、新年初出社の初仕事はAvailable Memory低下の原因究明でした。 まず、ステージング環境のAvailable Memoryの値を確認すると、ステージング環境では起きていないことがわかりました。 そこで、アクセス数が関係しているのでは?と考えました。 また、コードフリーズ日である
みんなのウェディングのインフラエンジニア横山です。 今回は開発用DBのマスク処理にEmbulk+Digdagを利用し始めた話について書きます。 開発用DBのマスク処理とは 弊社では、週次で本番DBのスナップショットから開発環境用DBを作り直しています。 これにより、常に本番環境と同じテーブル定義、データ量で開発を行うことができ、以下のようなメリットがあります。 本番にデプロイする前に、開発、ステージング環境で不具合を早期発見できる 実際に近いデータで、本番を想定した確認ができる ここで問題になってくるのが、ユーザの氏名やメールアドレスといった個人情報の扱いについてです。 開発用DBは本番DBのスナップショットから作成されているため、開発用DBにも本番DBの個人情報が入ってしまっています。 この状態で利用すると、以下にあげる問題が考えられます。 開発中の機能による、ユーザへのメール誤配信など
みんなのウェディング、松久(@kamonegi1977) です。 去る 1月18日(木)に「サービスを Ruby / Rails で成長させるためにやったこと(メドピア × みんなのウェディング)」と題して、エンジニア向けの勉強会を開催しました。 この勉強会では、メドピア株式会社、みんなのウェディングのエンジニアが、「サービスを Ruby / Rails で成長させるためにやったこと(メドピア × みんなのウェディング)」をテーマに、どうやってチームで開発力をつければいいのか?サービスの改善をどうやってスピーディーに行うのか?などのノウハウや知見を発表しました。 新卒がみんなのウェディングで MobaSifをRailsに移行してみた - テーブル設計編 -(黒澤) この発表のポイント 2017年新卒エンジニアがデーターベースリファクタリングに挑戦した どんな風にデータベースリファクタリング
こんにちは。みんなのウェディングのデザイナーの家高です。 今回はUXデザイン部がオーナーとなって定期的に実施しているユーザーインタビューについて紹介したいと思います。 ※掲載しているインタビューデータは個人情報を含むケースがあるのでダミーです。ご了承ください。 定期的にユーザーインタビューをおこなう目的 ユーザーに対する共通認識を持ちたい メンバーそれぞれが想像上のユーザーに対して開発するのでなく、ユーザーの声をベースにした共通認識を持つことでメンバー同士の認識ズレが少ない開発をしたいと考えています。 ユーザーの声を常にアップデートしたい 結婚式場を探すというサービスの都合上、自分達がなかなかユーザーになれないのでユーザーの声を常にアップデートし続ける必要があります。また、結婚式のあり方・トレンドは日々変化するため、いち早くキャッチアップしサービスに反映したいと考えています。 日々の業務に
こんにちは。みんなのウェディングのエンジニアの@1syoです。 みんなのウェディング Advent Calendar 2017 - Qiita 18日目の記事です。 Ruby on Rails のスローテスト対策としてやってみて、効果がなかったものとあったものをご紹介しようと思います。 効果がなかった springを利用する .circleci/config.yml - run: command: bin/spring server background: true - run: bin/spring rspec $(circleci tests glob "spec/** ... - run: bin/spring rspec $(circleci tests glob "spec/** ... このように spring server を起動してから spring 経由で RSpec を
この記事はmwedアドベントカレンダー11日目の記事です。 昨日の 最近使い始めた開発支援系サービスの話 に引き続き @koheisg が担当させていただきます。(2回目) エンジニアの幅を広げるという大層なことを書くと言ってしまいましたが、 この一年、みんなのウェディングで経験したCSS設計の経験を書こうと思います。 CSSの設計の話 CSSからサーバサイドのプログラミングまですべて、プログラマが担当するようになったとき、 まずオススメするのはシングルクラスのCSS設計です。 CSSはカスケーティングによって、記述をDRYにすることができますが、これはプログラミングの記述をDRYにする機能の継承やmixinよりも強力です。ですが、一歩間違うとすぐに設計が負債となってしまいます。 安易に継承しまくったオブジェクトの正体は突き止めにくいですよね? ですので、カスケーティングでクラスを記述する
はじめまして、みんなのウェディングのエンジニアの大須賀です。 「みんなのウェディング Advent Calendar 2017」の13日目の記事です。 とあるプルリクエストで、「order by rand()が使われていたので、to_aしてshuffleしました」という修正があったのを見て思ったことを書きます。 なぜ、order by rand()を使わないほうがいいのか まず「“Do not use ORDER BY RAND()” or “How to get random rows from table?”」 を読むのが良いと思います。日本語訳してくれている方もいるので、「ORDER BY RAND() 使うな」 のほうが読み易いです。 はい、読みましたね。使うなという理由は簡単で遅いからです。 ですから、使わないように修正するのは良いことだと思います。でも、修正の方法が良くなさそう
こんにちは。みんなのウェディングのエンジニアの@1syoです。 みんなのウェディング Advent Calendar 2017 - Qiita 11日目の記事です。 弊社ではGithubやCircleCIといった定番サービスは既に利用しています。 継続した開発プロセスの改善の一貫で最近導入した開発支援系サービスをご紹介しようと思います。 deppbot 定期的なbundle update にはtachikomaを利用していましたが、作者による開発終了宣言を受けてdeppbotに乗り換えました。 ChengelogやDiffをすぐに確認できるので破壊的変更の有無をすぐに確認できて便利です。 deppbot - Automated Security and Dependency Updates SideCI CircleCIでテスト実行する前に各種lintを実行してましたが、差分実行することが
みんなのウェディング Advent Calendar 2017 9日目の記事です。 ますます寒さ厳しくなる中、みなさまいかがお過ごしでしょうか。 みんなのウェディングのインフラエンジニア横山です。 11/27~12/1にかけてAWSのカンファレンスであるAWS re:Invent 2017が開催されました。 多数の新サービスがアナウンスされ、早速利用している方も多いのではないでしょうか。 弊社でも「Amazon Guard Durty」をお試しで導入しています。 AWS re:Invent 2017で発表された新サービス「Amazon Guard Durty」を早速使ってみた。 こちらの記事でもすこし触れておりますが、今回は同じく新サービスである、「Amazon Comprehend」を利用して口コミ分析をしてみたのでその結果についてレポートします。 Amazon Comprehendとは
Amazon Web Services Advent Calendar7日目の記事です。 寒さ厳しくなる中、みなさまいかがお過ごしでしょうか。 みんなのウェディングのインフラエンジニア横山です。 11/27~12/1にかけてAWSのカンファレンスであるAWS re:Invent 2017が開催されました。 多数の新サービスがアナウンスされ、早速利用している方も多いのではないでしょうか。 個人的には自然言語処理サービスである「Amazon Comprehend」に注目しています。 日本語対応が待ち遠しいところです。 さて、今回はそんな「Amazon Comprehend」ではなく、同じくre:Inventで発表された「Amazon Guard Durty」を利用してみたのでレポートします。 Amazon Guard Durtyとは 「Amazon Guard Durty」とは、AWS上のVP
新卒エンジニア研修を実施しました こんにちは。 みんなのウェディング技術部の武田です。 6月1日より技術部に配属になり、そこから7月31日までの約2ヶ月間の新卒エンジニア研修がありました。 もう冬に突入しようとしていますが、研修の様子とともに、実際に新卒の私が感じたこと、得たものを書いていきたいと思います。 研修の目的 今回の研修の目的は「Railsを利用してウェブアプリケーションを正しく作れる」ということを目指しています。単一に正しくというと広いですが、Webアプリケーションには設計、プログラム、セキュリティ、アプリケーションの信頼性と様々な切り口があります。それらを自ら学んで行きます。 17卒の新卒エンジニアは5名います。 (個性の強いメンバーに会いたい方はぜひオフィスに遊びに来て見てください!どこかに連絡くれれば反応します。) 各々Railsには初挑戦だったり、かじっていただけ、とい
こんにちは、技術部の坪井です。(みんなのウェディング)を2017年6月13日に完全HTTPS化しました。私達が行った完全HTTPS化の対応をご紹介します。 何故完全HTTPS化を行うのか 昨今インターネットの流れとして完全HTTPS化が進んできています。Webサイトの信頼性を高め、攻撃者からの盗聴・なりすましを防ぎユーザの個人情報を保護することが非常に重要となってきています。 また、新たなAPIや技術(HTTP/2など)において、HTTP通信化では利用が制限があるものも珍しくありません。 みんなのウェディング社では、既にPartyNoteを始めとした、Brides UP!など、2015年以降にリリースした新規サービスはリリース当初よりHTTPS化に対応しています。しかしながら、メインサービスである、みんなのウェディングは、対応規模が大きいためHTTPS化に踏み切れていませんでした。 これま
こんにちは。 みんなのウェディングの新卒1年目で技術部の濱口です。 みんなのウェディングは RubyKaigi2017 に Gold Sponsor として参加しました。 私を含む、2名のエンジニアがブース担当として参加しました。 たくさんの方にみんなのウェディングのブースに遊びにきていただきました。 本当にありがとうございました。 みんなのウェディングさんのブースにも置かせてもらいました(\( ⁰⊖⁰)/) ありがとうございます! #トノコト #esa_io #rubykaigi pic.twitter.com/MuVEgyzbiZ — esa_io (@esa_io) 2017年9月18日 大変お世話になっている esa のデザイナーさんからステッカーをいただきました。 Ruby && Rails コミッターの松田さんがブースに遊びにきてくれました というわけで今回は RubyKaig
みんなのウェディング、松久(@kamonegi1977) です。 去る 9月11日(月)に「「Ruby on Rails を使ったサービス開発と組織(ブラケット × みんなのウェディング)」と題して、エンジニア向けの勉強会を開催しました。 この勉強会では、STORES.jp(株式会社ブラケット)、みんなのウェディングのエンジニアが、「Ruby on Rails を使ったサービス開発と組織(ブラケット × みんなのウェディング)」をテーマに、サービス開発にまつわるチームビルディングのノウハウや知見を発表しました。 togetter の「「Ruby on Rails を使ったサービス開発と組織(ブラケット × みんなのウェディング)」のまとめ #Bracket_mwed」では、勉強会の雰囲気を感じとれるのではないかと思います。 STORES.jp開発チームのこれまでとこれから(矢部) この発表
みんなのウェディング、松久(@kamonegi1977) です。 利用している Ruby on Rails のバージョンを 4.2 から 5.0 にアップデートしました。 5.0 へのアップデートで行った事をまとめます。 アップデートまでの流れ Rails 5 へのアップデートプルリクエストができる 作られたプルリクエストを開発環境にデプロイし、手動でブラウザ確認する 日々の変更を毎日取り込む 手動でのブラウザ確認、リリース後見つかったエラーは、再現テストを作って対応する プルリクエストをマージしてリリースする 最初、アップデートに必要なことをプルリクエストを用意しました。 その後、ブラウザ確認を行いエラーになったところを見つけたら再現テストを用意していき、リリースをしました。 gem の変更と削除 gem のアップデートは、日々追従していますが、Rails 5.0 に合わせて変更や追加が
みんなのウェディングのインフラエンジニア横山です。 みんなのウェディングでは先日、データベースを RDS for MySQL から Amazon Aurora (以下 Aurora )へ移行しました。 この記事では移行の経緯や移行手順、移行後の感想についてまとめたいと思います。 移行の経緯 みんなのウェディングでは結婚式場口コミサイトのみんなのウェディングを運営しています。 本サービスではサービス開始当初から MySQL を利用しており、 AWS 移行時にも RDS for MySQL を選択していました。 今回、 Aurora 移行を決めた理由は以下の3つのメリットがあったからです。 1. リーダーエンドポイントによるリードレプリカの冗長化 Aurora にはリーダーエンドポイントという読み込み専用エンドポイントがあります。 https://aws.amazon.com/jp/blogs
我が家の小さな庭の芝も若葉色に色づく季節になってまいりました。 こんにちは。 株式会社みんなのウェディング、エンジニアの中村です。 現在は主に花嫁限定SNSアプリ「Brides UP!(ブライズアップ)」のWebアプリケーション開発を担当しております。 Brides UP!は結婚式のアイデアさがしや花嫁同士で情報交換するコミニケーションツールです。 結婚式は誰もが初めてでわからないことが多く、それらを招待する友人などに相談することも難しい現状があります。 立場が同じ花嫁さんたちが、それぞれの経験を共有することで不安を解消し理想の結婚式への準備を楽しく進めることができます。 花嫁さんが最高の1日を迎えられるよう「花嫁さん同士がつながる」ことを大切にし、日々開発を行っております。 今回はHeroku CIを現在稼働中のサービスBrides UP!に導入したのでその経緯と手順についてご紹介します
みんなのウェディングのインフラエンジニア横山です。 今回は、itamae利用時の機密情報管理をGoogle スプレッドシートから yaml_vault に移行したのでそのことについて書きます。 機密情報とは何か みんなのウェディングの環境では、ryotaraiさんが作成した itamae によるインフラのコード管理を行っています。 itamaeには任意のテンプレートファイルをサーバに配置する機能(https://github.com/itamae-kitchen/itamae/wiki/template-resource) があり、こちらの機能を使って様々なファイルをレポジトリで管理しています。 �そういった管理対象のファイルの中には以下に挙げるような、レポジトリへのコミットを控えたほうが良いが、なにかしらの手段で管理しておくべき情報が存在します。 DBのパスワード アプリが利用するAPI
はじめまして、みんなのウェディング 横山です。 ご覧いただいてる通り、みんなのウェディングではエンジニアリングブログを運営しています。今回、エンジニアリングブログのCI環境をCodePipeline&CodeBuildへ移行したので概要をお伝えします。 エンジニアリングブログは何を使って構築されているのか。 middleman という静的サイト構築用のフレームワークを利用しています。 middlemanでは記事の追加・修正後、HTMLファイルを再生成するためにビルド作業を行う必要があります。 みんなのウェディングのエンジニアリングブログでは、記事の追加・修正はマスターブランチへ変更をマージすることで行っています。こうすることで、マスターへのマージをトリガーにビルド作業および生成されたHTMLファイルのデプロイを自動で行うことができます。 ビルド&デプロイ自動化の仕組み これまでは、Circ
こんにちは。みんなのウェディングの園田です。 みんなのウェディングのUXデザイン部では、18卒新卒デザイナー志望の学生を対象に1Dayインターンを実施しました。 このインターンを企画したのは「サービスデザインに興味はあるけど、どんな業界が向いているか決めきれてない学生にチャレンジしてもらいたい」という思いからです。 今回のゴールは、 学生側はサービスデザイナーのお仕事体験とUI/UXの手法を学ぶこと、 企業側は自社に興味を持ってもらい、採用のエントリー数を増やすこと、です。 インターンで作るもののテーマは 「初めて結婚式に呼ばれたゲスト」が「招待状をもらってから結婚式当日までに使うプロダクト」です。 学生たちはまずUX概論について勉強したあと、 「ユーザーの行動や感情から欲求と課題を分析する」 「見つけた課題を解決するためのプロダクトを考える」 「それをプロトタイプに起こして発表する」 と
みんなのウェディング、松久(@kamonegi1977)です。 みんなのウェディングでは、アジャイル開発を導入して1年以上が経ちました。現在、どんな組織・チームでサービス開発をすすめているのかを説明します。 なぜ?アジャイル開発を導入したのか アジャイル開発を導入する前は、以下のような流れで開発が行われていました。 マーケティングから企画がまとめられて、開発依頼が出される 開発担当がアサインされ、デザイナー、エンジニアが決まる Excel などで仕様書(画面構成)があり、リリース日が決まっている リリースすると開発終了。次の開発へ(1に戻る) この流れは、エンジニアが1つの開発に集中できるメリットがあります。 一方でリリース日が重視されるため、機能や品質が犠牲となることがありました。リリースを終えると次の開発に入ることが多く、リリースした新機能や変更を改善することが難しい状態でした。チーム
次のページ
このページを最初にブックマークしてみませんか?
『みんなのウェディングエンジニアリングブログ』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く