こんにちは、開発本部の宮内です。 さて、これまで弊社のオンライン診療アプリ「 CLINICS 」では、ローンチ時より Heroku を利用しておりました。 Heroku とは、PaaS の一種で Web アプリケーションを簡単にデプロイ、ホスティングできるサービスです。 ある程度の制約はつきますが、(大体の制約は金で解決できるので)使っているかたも多いのではないでしょうか。 今回、事情により Heroku から AWS Elastic Beanstalk (以下、EB)へ移行することになりましたので、そのあたりでやったことを共有できればと思います。 Private PaaS にしないの？ まずはじめに移行にあたり、Priavte PaaS を構築する方法を模索しました。 ですが、これらのクラスタの構築はできても、専任の(Ops|SRE|インフラ)チームがいないため、日々の管理や運用に手が回らないだろうという思いから、Private PaaS の構築は見送りました。 この辺りは今後チーム人数が増えたら挑戦していきたいです…。 検討時、参考にしたリンク PAAS comparison - Dokku vs Flynn vs Deis vs Kubernetes vs Docker Swarm (2017) Convox Deis Flynn なぜ AWS Elastic Beanstalk にしたの？ EB には Rails や Sinatra で作成されたウェブアプリケーションを実行するための Ruby プラットフォーム が予め用意されております。 ただし、今回の移行では、アプリケーションへの変更を一切加えずに行いたかったため、Ruby プラットフォームを利用しませんでした。 代わりに Docker コンテナが実行できる プラットフォーム があったため、そちらを使うことにしました。 herokuish で Docker イメージを作成 アプリケーションの Docker イメージ化には、 gliderlabs/herokuish を使いました。 これは buildpack を使いアプリケーションを slug 化したり、slug を実行するためのツールです。 Docker イメージ作成の手順は以下の通りです。 herokuish buildpack build と herokuish slug generate でアプリケーションを slug にする herokuish slug import で slug をインポートして完成 それでは、それぞれ簡単に説明していきたいと思います。 アプリケーションを slug にする docker pull gliderlabs/herokuish docker run \ -v "/path/to/app:/tmp/build" \ -v "/path/to/cache:/tmp/cache" \ -v "/path/to/slug:/tmp/slug" \ gliderlabs/herokuish \ /bin/bash -c 'herokuish buildpack build && herokuish slug generate && herokuish slug export > /tmp/slug/slug.tgz' herokuish は特定のディレクトリに対して処理を行います。↑ ではビルドするアプリケーションまでのディレクトリパスを /tmp/build にマッピングしています。 /tmp/cache は buildpack が利用するキャッシュ置き場です。このディレクトリを次回以降のビルドでもマッピングしておくとビルドの高速化が見込めます。 最後の /tmp/slug はビルドした slug をコンテナからホストへコピーするために指定しています。(これは herokuish で用意されてるものではなくコンテナからホストへファイルをコピーする方法を悩んだ末のアドホックな対応です…) 他にも様々なディレクトリがあります。詳しくは ドキュメント をご覧ください。 slug をインポートする 次に作成した slug を使いアプリケーションの Docker イメージをつくります。 cd $( mktemp -d ) mv /path/to/slug/slug.tgz . echo ' FROM gliderlabs/herokuish COPY slug.tgz /tmp/slug.tgz RUN cat /tmp/slug.tgz | herokuish slug import && rm /tmp/slug.tgz EXPOSE 5000 ' > Dockerfile docker build -f Dockerfile . docker build 時に Context としてカレントディレクトリ全体が送られるため、一時ディレクトリを作成しその中で docker build を行っています。 終わり CLINICS では上記のような手段で作成した Docker イメージを Amazon EC2 Container Registry にアップロードし EB 上で実行しています。 本来であれば、アプリケーションを slug にする部分と、slug をインポートする部分を分割しなくても良いと思いますが、CircleCI で Docker イメージを作成する関係上でこのような方法になりました。 先日 GA となった CircleCI 2.0 にはまだ対応できていないので、今後の課題としたいと思います。 お知らせ メドレーでは、CLINICS だけでなく、医療介護の求人サイト「 ジョブメドレー 」、医師たちがつくるオンライン医療事典「 MEDLEY 」、口コミで探せる介護施設の検索サイト「 介護のほんね 」などのプロダクトも提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。 https://www.medley.jp/recruit/creative.html メドレーで一緒に医療体験を変えるプロダクト作りに関わりたい方のご連絡お待ちしております。

こんにちは、開発本部の宮内です。 さて、これまで弊社のオンライン診療アプリ「 CLINICS 」では、ローンチ時より Heroku を利用しておりました。 Heroku とは、PaaS の一種で Web アプリケーションを簡単にデプロイ、ホスティングできるサービスです。 ある程度の制約はつきますが、(大体の制約は金で解決できるので)使っているかたも多いのではないでしょうか。 今回、事情により Heroku から AWS Elastic Beanstalk (以下、EB)へ移行することになりましたので、そのあたりでやったことを共有できればと思います。 Private PaaS にしないの？ まずはじめに移行にあたり、Priavte PaaS を構築する方法を模索しました。 ですが、これらのクラスタの構築はできても、専任の(Ops|SRE|インフラ)チームがいないため、日々の管理や運用に手が回らないだろうという思いから、Private PaaS の構築は見送りました。 この辺りは今後チーム人数が増えたら挑戦していきたいです…。 検討時、参考にしたリンク PAAS comparison - Dokku vs Flynn vs Deis vs Kubernetes vs Docker Swarm (2017) Convox Deis Flynn なぜ AWS Elastic Beanstalk にしたの？ EB には Rails や Sinatra で作成されたウェブアプリケーションを実行するための Ruby プラットフォーム が予め用意されております。 ただし、今回の移行では、アプリケーションへの変更を一切加えずに行いたかったため、Ruby プラットフォームを利用しませんでした。 代わりに Docker コンテナが実行できる プラットフォーム があったため、そちらを使うことにしました。 herokuish で Docker イメージを作成 アプリケーションの Docker イメージ化には、 gliderlabs/herokuish を使いました。 これは buildpack を使いアプリケーションを slug 化したり、slug を実行するためのツールです。 Docker イメージ作成の手順は以下の通りです。 herokuish buildpack build と herokuish slug generate でアプリケーションを slug にする herokuish slug import で slug をインポートして完成 それでは、それぞれ簡単に説明していきたいと思います。 アプリケーションを slug にする docker pull gliderlabs/herokuish docker run \ -v "/path/to/app:/tmp/build" \ -v "/path/to/cache:/tmp/cache" \ -v "/path/to/slug:/tmp/slug" \ gliderlabs/herokuish \ /bin/bash -c 'herokuish buildpack build && herokuish slug generate && herokuish slug export > /tmp/slug/slug.tgz' herokuish は特定のディレクトリに対して処理を行います。↑ ではビルドするアプリケーションまでのディレクトリパスを /tmp/build にマッピングしています。 /tmp/cache は buildpack が利用するキャッシュ置き場です。このディレクトリを次回以降のビルドでもマッピングしておくとビルドの高速化が見込めます。 最後の /tmp/slug はビルドした slug をコンテナからホストへコピーするために指定しています。(これは herokuish で用意されてるものではなくコンテナからホストへファイルをコピーする方法を悩んだ末のアドホックな対応です…) 他にも様々なディレクトリがあります。詳しくは ドキュメント をご覧ください。 slug をインポートする 次に作成した slug を使いアプリケーションの Docker イメージをつくります。 cd $( mktemp -d ) mv /path/to/slug/slug.tgz . echo ' FROM gliderlabs/herokuish COPY slug.tgz /tmp/slug.tgz RUN cat /tmp/slug.tgz | herokuish slug import && rm /tmp/slug.tgz EXPOSE 5000 ' > Dockerfile docker build -f Dockerfile . docker build 時に Context としてカレントディレクトリ全体が送られるため、一時ディレクトリを作成しその中で docker build を行っています。 終わり CLINICS では上記のような手段で作成した Docker イメージを Amazon EC2 Container Registry にアップロードし EB 上で実行しています。 本来であれば、アプリケーションを slug にする部分と、slug をインポートする部分を分割しなくても良いと思いますが、CircleCI で Docker イメージを作成する関係上でこのような方法になりました。 先日 GA となった CircleCI 2.0 にはまだ対応できていないので、今後の課題としたいと思います。 お知らせ メドレーでは、CLINICS だけでなく、医療介護の求人サイト「 ジョブメドレー 」、医師たちがつくるオンライン医療事典「 MEDLEY 」、口コミで探せる介護施設の検索サイト「 介護のほんね 」などのプロダクトも提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。 メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp メドレーで一緒に医療体験を変えるプロダクト作りに関わりたい方のご連絡お待ちしております。

こんにちは、開発本部の宮内です。 さて、これまで弊社のオンライン診療アプリ「 CLINICS 」では、ローンチ時より Heroku を利用しておりました。 Heroku とは、PaaS の一種で Web アプリケーションを簡単にデプロイ、ホスティングできるサービスです。 ある程度の制約はつきますが、(大体の制約は金で解決できるので)使っているかたも多いのではないでしょうか。 今回、事情により Heroku から AWS Elastic Beanstalk (以下、EB)へ移行することになりましたので、そのあたりでやったことを共有できればと思います。 Private PaaS にしないの？ まずはじめに移行にあたり、Priavte PaaS を構築する方法を模索しました。 ですが、これらのクラスタの構築はできても、専任の(Ops|SRE|インフラ)チームがいないため、日々の管理や運用に手が回らないだろうという思いから、Private PaaS の構築は見送りました。 この辺りは今後チーム人数が増えたら挑戦していきたいです…。 検討時、参考にしたリンク PAAS comparison - Dokku vs Flynn vs Deis vs Kubernetes vs Docker Swarm (2017) Convox Deis Flynn なぜ AWS Elastic Beanstalk にしたの？ EB には Rails や Sinatra で作成されたウェブアプリケーションを実行するための Ruby プラットフォーム が予め用意されております。 ただし、今回の移行では、アプリケーションへの変更を一切加えずに行いたかったため、Ruby プラットフォームを利用しませんでした。 代わりに Docker コンテナが実行できる プラットフォーム があったため、そちらを使うことにしました。 herokuish で Docker イメージを作成 アプリケーションの Docker イメージ化には、 gliderlabs/herokuish を使いました。 これは buildpack を使いアプリケーションを slug 化したり、slug を実行するためのツールです。 Docker イメージ作成の手順は以下の通りです。 herokuish buildpack build と herokuish slug generate でアプリケーションを slug にする herokuish slug import で slug をインポートして完成 それでは、それぞれ簡単に説明していきたいと思います。 アプリケーションを slug にする docker pull gliderlabs/herokuish docker run \ -v "/path/to/app:/tmp/build" \ -v "/path/to/cache:/tmp/cache" \ -v "/path/to/slug:/tmp/slug" \ gliderlabs/herokuish \ /bin/bash -c 'herokuish buildpack build && herokuish slug generate && herokuish slug export > /tmp/slug/slug.tgz' herokuish は特定のディレクトリに対して処理を行います。↑ ではビルドするアプリケーションまでのディレクトリパスを /tmp/build にマッピングしています。 /tmp/cache は buildpack が利用するキャッシュ置き場です。このディレクトリを次回以降のビルドでもマッピングしておくとビルドの高速化が見込めます。 最後の /tmp/slug はビルドした slug をコンテナからホストへコピーするために指定しています。(これは herokuish で用意されてるものではなくコンテナからホストへファイルをコピーする方法を悩んだ末のアドホックな対応です…) 他にも様々なディレクトリがあります。詳しくは ドキュメント をご覧ください。 slug をインポートする 次に作成した slug を使いアプリケーションの Docker イメージをつくります。 cd $( mktemp -d ) mv /path/to/slug/slug.tgz . echo ' FROM gliderlabs/herokuish COPY slug.tgz /tmp/slug.tgz RUN cat /tmp/slug.tgz | herokuish slug import && rm /tmp/slug.tgz EXPOSE 5000 ' > Dockerfile docker build -f Dockerfile . docker build 時に Context としてカレントディレクトリ全体が送られるため、一時ディレクトリを作成しその中で docker build を行っています。 終わり CLINICS では上記のような手段で作成した Docker イメージを Amazon EC2 Container Registry にアップロードし EB 上で実行しています。 本来であれば、アプリケーションを slug にする部分と、slug をインポートする部分を分割しなくても良いと思いますが、CircleCI で Docker イメージを作成する関係上でこのような方法になりました。 先日 GA となった CircleCI 2.0 にはまだ対応できていないので、今後の課題としたいと思います。 お知らせ メドレーでは、CLINICS だけでなく、医療介護の求人サイト「 ジョブメドレー 」、医師たちがつくるオンライン医療事典「 MEDLEY 」、口コミで探せる介護施設の検索サイト「 介護のほんね 」などのプロダクトも提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。 メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp メドレーで一緒に医療体験を変えるプロダクト作りに関わりたい方のご連絡お待ちしております。

こんにちは、開発本部の宮内です。 さて、これまで弊社のオンライン診療アプリ「 CLINICS 」では、ローンチ時より Heroku を利用しておりました。 Heroku とは、PaaS の一種で Web アプリケーションを簡単にデプロイ、ホスティングできるサービスです。 ある程度の制約はつきますが、(大体の制約は金で解決できるので)使っているかたも多いのではないでしょうか。 今回、事情により Heroku から AWS Elastic Beanstalk (以下、EB)へ移行することになりましたので、そのあたりでやったことを共有できればと思います。 Private PaaS にしないの？ まずはじめに移行にあたり、Priavte PaaS を構築する方法を模索しました。 ですが、これらのクラスタの構築はできても、専任の(Ops|SRE|インフラ)チームがいないため、日々の管理や運用に手が回らないだろうという思いから、Private PaaS の構築は見送りました。 この辺りは今後チーム人数が増えたら挑戦していきたいです…。 検討時、参考にしたリンク PAAS comparison - Dokku vs Flynn vs Deis vs Kubernetes vs Docker Swarm (2017) Convox Deis Flynn なぜ AWS Elastic Beanstalk にしたの？ EB には Rails や Sinatra で作成されたウェブアプリケーションを実行するための Ruby プラットフォーム が予め用意されております。 ただし、今回の移行では、アプリケーションへの変更を一切加えずに行いたかったため、Ruby プラットフォームを利用しませんでした。 代わりに Docker コンテナが実行できる プラットフォーム があったため、そちらを使うことにしました。 herokuish で Docker イメージを作成 アプリケーションの Docker イメージ化には、 gliderlabs/herokuish を使いました。 これは buildpack を使いアプリケーションを slug 化したり、slug を実行するためのツールです。 Docker イメージ作成の手順は以下の通りです。 herokuish buildpack build と herokuish slug generate でアプリケーションを slug にする herokuish slug import で slug をインポートして完成 それでは、それぞれ簡単に説明していきたいと思います。 アプリケーションを slug にする docker pull gliderlabs/herokuish docker run \ -v "/path/to/app:/tmp/build" \ -v "/path/to/cache:/tmp/cache" \ -v "/path/to/slug:/tmp/slug" \ gliderlabs/herokuish \ /bin/bash -c 'herokuish buildpack build && herokuish slug generate && herokuish slug export > /tmp/slug/slug.tgz' herokuish は特定のディレクトリに対して処理を行います。↑ ではビルドするアプリケーションまでのディレクトリパスを /tmp/build にマッピングしています。 /tmp/cache は buildpack が利用するキャッシュ置き場です。このディレクトリを次回以降のビルドでもマッピングしておくとビルドの高速化が見込めます。 最後の /tmp/slug はビルドした slug をコンテナからホストへコピーするために指定しています。(これは herokuish で用意されてるものではなくコンテナからホストへファイルをコピーする方法を悩んだ末のアドホックな対応です…) 他にも様々なディレクトリがあります。詳しくは ドキュメント をご覧ください。 slug をインポートする 次に作成した slug を使いアプリケーションの Docker イメージをつくります。 cd $( mktemp -d ) mv /path/to/slug/slug.tgz . echo ' FROM gliderlabs/herokuish COPY slug.tgz /tmp/slug.tgz RUN cat /tmp/slug.tgz | herokuish slug import && rm /tmp/slug.tgz EXPOSE 5000 ' > Dockerfile docker build -f Dockerfile . docker build 時に Context としてカレントディレクトリ全体が送られるため、一時ディレクトリを作成しその中で docker build を行っています。 終わり CLINICS では上記のような手段で作成した Docker イメージを Amazon EC2 Container Registry にアップロードし EB 上で実行しています。 本来であれば、アプリケーションを slug にする部分と、slug をインポートする部分を分割しなくても良いと思いますが、CircleCI で Docker イメージを作成する関係上でこのような方法になりました。 先日 GA となった CircleCI 2.0 にはまだ対応できていないので、今後の課題としたいと思います。 お知らせ メドレーでは、CLINICS だけでなく、医療介護の求人サイト「 ジョブメドレー 」、医師たちがつくるオンライン医療事典「 MEDLEY 」、口コミで探せる介護施設の検索サイト「 介護のほんね 」などのプロダクトも提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。 メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp メドレーで一緒に医療体験を変えるプロダクト作りに関わりたい方のご連絡お待ちしております。

こんにちは、開発本部の宮内です。 さて、これまで弊社のオンライン診療アプリ「 CLINICS 」では、ローンチ時より Heroku を利用しておりました。 Heroku とは、PaaS の一種で Web アプリケーションを簡単にデプロイ、ホスティングできるサービスです。 ある程度の制約はつきますが、(大体の制約は金で解決できるので)使っているかたも多いのではないでしょうか。 今回、事情により Heroku から AWS Elastic Beanstalk (以下、EB)へ移行することになりましたので、そのあたりでやったことを共有できればと思います。 Private PaaS にしないの？ まずはじめに移行にあたり、Priavte PaaS を構築する方法を模索しました。 ですが、これらのクラスタの構築はできても、専任の(Ops|SRE|インフラ)チームがいないため、日々の管理や運用に手が回らないだろうという思いから、Private PaaS の構築は見送りました。 この辺りは今後チーム人数が増えたら挑戦していきたいです…。 検討時、参考にしたリンク PAAS comparison - Dokku vs Flynn vs Deis vs Kubernetes vs Docker Swarm (2017) Convox Deis Flynn なぜ AWS Elastic Beanstalk にしたの？ EB には Rails や Sinatra で作成されたウェブアプリケーションを実行するための Ruby プラットフォーム が予め用意されております。 ただし、今回の移行では、アプリケーションへの変更を一切加えずに行いたかったため、Ruby プラットフォームを利用しませんでした。 代わりに Docker コンテナが実行できる プラットフォーム があったため、そちらを使うことにしました。 herokuish で Docker イメージを作成 アプリケーションの Docker イメージ化には、 gliderlabs/herokuish を使いました。 これは buildpack を使いアプリケーションを slug 化したり、slug を実行するためのツールです。 Docker イメージ作成の手順は以下の通りです。 herokuish buildpack build と herokuish slug generate でアプリケーションを slug にする herokuish slug import で slug をインポートして完成 それでは、それぞれ簡単に説明していきたいと思います。 アプリケーションを slug にする docker pull gliderlabs/herokuish docker run \ -v "/path/to/app:/tmp/build" \ -v "/path/to/cache:/tmp/cache" \ -v "/path/to/slug:/tmp/slug" \ gliderlabs/herokuish \ /bin/bash -c 'herokuish buildpack build && herokuish slug generate && herokuish slug export > /tmp/slug/slug.tgz' herokuish は特定のディレクトリに対して処理を行います。↑ ではビルドするアプリケーションまでのディレクトリパスを /tmp/build にマッピングしています。 /tmp/cache は buildpack が利用するキャッシュ置き場です。このディレクトリを次回以降のビルドでもマッピングしておくとビルドの高速化が見込めます。 最後の /tmp/slug はビルドした slug をコンテナからホストへコピーするために指定しています。(これは herokuish で用意されてるものではなくコンテナからホストへファイルをコピーする方法を悩んだ末のアドホックな対応です…) 他にも様々なディレクトリがあります。詳しくは ドキュメント をご覧ください。 slug をインポートする 次に作成した slug を使いアプリケーションの Docker イメージをつくります。 cd $( mktemp -d ) mv /path/to/slug/slug.tgz . echo ' FROM gliderlabs/herokuish COPY slug.tgz /tmp/slug.tgz RUN cat /tmp/slug.tgz | herokuish slug import && rm /tmp/slug.tgz EXPOSE 5000 ' > Dockerfile docker build -f Dockerfile . docker build 時に Context としてカレントディレクトリ全体が送られるため、一時ディレクトリを作成しその中で docker build を行っています。 終わり CLINICS では上記のような手段で作成した Docker イメージを Amazon EC2 Container Registry にアップロードし EB 上で実行しています。 本来であれば、アプリケーションを slug にする部分と、slug をインポートする部分を分割しなくても良いと思いますが、CircleCI で Docker イメージを作成する関係上でこのような方法になりました。 先日 GA となった CircleCI 2.0 にはまだ対応できていないので、今後の課題としたいと思います。 お知らせ メドレーでは、CLINICS だけでなく、医療介護の求人サイト「 ジョブメドレー 」、医師たちがつくるオンライン医療事典「 MEDLEY 」、口コミで探せる介護施設の検索サイト「 介護のほんね 」などのプロダクトも提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。 メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp メドレーで一緒に医療体験を変えるプロダクト作りに関わりたい方のご連絡お待ちしております。

こんにちは、開発本部の宮内です。 さて、これまで弊社のオンライン診療アプリ「 CLINICS 」では、ローンチ時より Heroku を利用しておりました。 Heroku とは、PaaS の一種で Web アプリケーションを簡単にデプロイ、ホスティングできるサービスです。 ある程度の制約はつきますが、(大体の制約は金で解決できるので)使っているかたも多いのではないでしょうか。 今回、事情により Heroku から AWS Elastic Beanstalk (以下、EB)へ移行することになりましたので、そのあたりでやったことを共有できればと思います。 Private PaaS にしないの？ まずはじめに移行にあたり、Priavte PaaS を構築する方法を模索しました。 ですが、これらのクラスタの構築はできても、専任の(Ops|SRE|インフラ)チームがいないため、日々の管理や運用に手が回らないだろうという思いから、Private PaaS の構築は見送りました。 この辺りは今後チーム人数が増えたら挑戦していきたいです…。 検討時、参考にしたリンク PAAS comparison - Dokku vs Flynn vs Deis vs Kubernetes vs Docker Swarm (2017) Convox Deis Flynn なぜ AWS Elastic Beanstalk にしたの？ EB には Rails や Sinatra で作成されたウェブアプリケーションを実行するための Ruby プラットフォーム が予め用意されております。 ただし、今回の移行では、アプリケーションへの変更を一切加えずに行いたかったため、Ruby プラットフォームを利用しませんでした。 代わりに Docker コンテナが実行できる プラットフォーム があったため、そちらを使うことにしました。 herokuish で Docker イメージを作成 アプリケーションの Docker イメージ化には、 gliderlabs/herokuish を使いました。 これは buildpack を使いアプリケーションを slug 化したり、slug を実行するためのツールです。 Docker イメージ作成の手順は以下の通りです。 herokuish buildpack build と herokuish slug generate でアプリケーションを slug にする herokuish slug import で slug をインポートして完成 それでは、それぞれ簡単に説明していきたいと思います。 アプリケーションを slug にする docker pull gliderlabs/herokuish docker run \ -v "/path/to/app:/tmp/build" \ -v "/path/to/cache:/tmp/cache" \ -v "/path/to/slug:/tmp/slug" \ gliderlabs/herokuish \ /bin/bash -c 'herokuish buildpack build && herokuish slug generate && herokuish slug export > /tmp/slug/slug.tgz' herokuish は特定のディレクトリに対して処理を行います。↑ ではビルドするアプリケーションまでのディレクトリパスを /tmp/build にマッピングしています。 /tmp/cache は buildpack が利用するキャッシュ置き場です。このディレクトリを次回以降のビルドでもマッピングしておくとビルドの高速化が見込めます。 最後の /tmp/slug はビルドした slug をコンテナからホストへコピーするために指定しています。(これは herokuish で用意されてるものではなくコンテナからホストへファイルをコピーする方法を悩んだ末のアドホックな対応です…) 他にも様々なディレクトリがあります。詳しくは ドキュメント をご覧ください。 slug をインポートする 次に作成した slug を使いアプリケーションの Docker イメージをつくります。 cd $( mktemp -d ) mv /path/to/slug/slug.tgz . echo ' FROM gliderlabs/herokuish COPY slug.tgz /tmp/slug.tgz RUN cat /tmp/slug.tgz | herokuish slug import && rm /tmp/slug.tgz EXPOSE 5000 ' > Dockerfile docker build -f Dockerfile . docker build 時に Context としてカレントディレクトリ全体が送られるため、一時ディレクトリを作成しその中で docker build を行っています。 終わり CLINICS では上記のような手段で作成した Docker イメージを Amazon EC2 Container Registry にアップロードし EB 上で実行しています。 本来であれば、アプリケーションを slug にする部分と、slug をインポートする部分を分割しなくても良いと思いますが、CircleCI で Docker イメージを作成する関係上でこのような方法になりました。 先日 GA となった CircleCI 2.0 にはまだ対応できていないので、今後の課題としたいと思います。 お知らせ メドレーでは、CLINICS だけでなく、医療介護の求人サイト「 ジョブメドレー 」、医師たちがつくるオンライン医療事典「 MEDLEY 」、口コミで探せる介護施設の検索サイト「 介護のほんね 」などのプロダクトも提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。 メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp メドレーで一緒に医療体験を変えるプロダクト作りに関わりたい方のご連絡お待ちしております。

こんにちは、開発本部の宮内です。 さて、これまで弊社のオンライン診療アプリ「 CLINICS 」では、ローンチ時より Heroku を利用しておりました。 Heroku とは、PaaS の一種で Web アプリケーションを簡単にデプロイ、ホスティングできるサービスです。 ある程度の制約はつきますが、(大体の制約は金で解決できるので)使っているかたも多いのではないでしょうか。 今回、事情により Heroku から AWS Elastic Beanstalk (以下、EB)へ移行することになりましたので、そのあたりでやったことを共有できればと思います。 Private PaaS にしないの？ まずはじめに移行にあたり、Priavte PaaS を構築する方法を模索しました。 ですが、これらのクラスタの構築はできても、専任の(Ops|SRE|インフラ)チームがいないため、日々の管理や運用に手が回らないだろうという思いから、Private PaaS の構築は見送りました。 この辺りは今後チーム人数が増えたら挑戦していきたいです…。 検討時、参考にしたリンク PAAS comparison - Dokku vs Flynn vs Deis vs Kubernetes vs Docker Swarm (2017) Convox Deis Flynn なぜ AWS Elastic Beanstalk にしたの？ EB には Rails や Sinatra で作成されたウェブアプリケーションを実行するための Ruby プラットフォーム が予め用意されております。 ただし、今回の移行では、アプリケーションへの変更を一切加えずに行いたかったため、Ruby プラットフォームを利用しませんでした。 代わりに Docker コンテナが実行できる プラットフォーム があったため、そちらを使うことにしました。 herokuish で Docker イメージを作成 アプリケーションの Docker イメージ化には、 gliderlabs/herokuish を使いました。 これは buildpack を使いアプリケーションを slug 化したり、slug を実行するためのツールです。 Docker イメージ作成の手順は以下の通りです。 herokuish buildpack build と herokuish slug generate でアプリケーションを slug にする herokuish slug import で slug をインポートして完成 それでは、それぞれ簡単に説明していきたいと思います。 アプリケーションを slug にする docker pull gliderlabs/herokuish docker run \ -v "/path/to/app:/tmp/build" \ -v "/path/to/cache:/tmp/cache" \ -v "/path/to/slug:/tmp/slug" \ gliderlabs/herokuish \ /bin/bash -c 'herokuish buildpack build && herokuish slug generate && herokuish slug export > /tmp/slug/slug.tgz' herokuish は特定のディレクトリに対して処理を行います。↑ ではビルドするアプリケーションまでのディレクトリパスを /tmp/build にマッピングしています。 /tmp/cache は buildpack が利用するキャッシュ置き場です。このディレクトリを次回以降のビルドでもマッピングしておくとビルドの高速化が見込めます。 最後の /tmp/slug はビルドした slug をコンテナからホストへコピーするために指定しています。(これは herokuish で用意されてるものではなくコンテナからホストへファイルをコピーする方法を悩んだ末のアドホックな対応です…) 他にも様々なディレクトリがあります。詳しくは ドキュメント をご覧ください。 slug をインポートする 次に作成した slug を使いアプリケーションの Docker イメージをつくります。 cd $( mktemp -d ) mv /path/to/slug/slug.tgz . echo ' FROM gliderlabs/herokuish COPY slug.tgz /tmp/slug.tgz RUN cat /tmp/slug.tgz | herokuish slug import && rm /tmp/slug.tgz EXPOSE 5000 ' > Dockerfile docker build -f Dockerfile . docker build 時に Context としてカレントディレクトリ全体が送られるため、一時ディレクトリを作成しその中で docker build を行っています。 終わり CLINICS では上記のような手段で作成した Docker イメージを Amazon EC2 Container Registry にアップロードし EB 上で実行しています。 本来であれば、アプリケーションを slug にする部分と、slug をインポートする部分を分割しなくても良いと思いますが、CircleCI で Docker イメージを作成する関係上でこのような方法になりました。 先日 GA となった CircleCI 2.0 にはまだ対応できていないので、今後の課題としたいと思います。 お知らせ メドレーでは、CLINICS だけでなく、医療介護の求人サイト「 ジョブメドレー 」、医師たちがつくるオンライン医療事典「 MEDLEY 」、口コミで探せる介護施設の検索サイト「 介護のほんね 」などのプロダクトも提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。 メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp メドレーで一緒に医療体験を変えるプロダクト作りに関わりたい方のご連絡お待ちしております。

はじめまして！最近みるみる太りだしてはいるものの、まだ機は熟していないとダイエットの時期をぐっと堪えている開発本部イケメン担当のデザイナー・小山です。 メドレーでは TechLunch という社内勉強会を実施しているのですが、 前田 に引き続き私も発表する機会をいただきましたので、その内容を紹介させていただきます。テーマは「思考とデザインスキル」です。発表資料は記事の最後をご覧ください。 テーマに入るまえに… みなさん『黄金比』ってご存知ですか？ 黄金比は美しいとされる物の形に共通してみられる比率で、古くから絵画や彫刻、建築などに使われています。デザイナーであれば、一度以上は使ったことあるのではないでしょうか？私もデザイナーなので何度も使っています。 ただ使ってはいるものの、なぜ美しくなるのか上手く説明ができません。当たり前のように世の中に広まっていて『困ったときの黄金比！』といった安易な思考で使っています。三十路を軽く超えたのでそれではいけないと思い、すこし調べてみました。 そもそも黄金比はエウクレイデスというユーグリッド幾何学を体系化した数学者が見つけた比率なのですが、そのとき彼は『黄金比＝美しい』とは明言していないそうです。自然物や人工物の形には一定の比率で成り立っていると考え、その比率に黄金比と名付けだけとのこと。 その後、その使いやすさから至るところで活用され、その比率に親しみが芽生え巷で受け入れられるようになりました。 認知心理学では、それを『 単純接触効果 』と呼びます。たくさん触れるうちに親しみが沸く機能が人にはもともと備わっていて、黄金比をつかったものが美しく見えるのもその影響ではないか？と言われています。この説を聞いた時、基礎的なのに原理が曖昧なデザイナーのスキルの輪郭がすこしだけハッキリしてきました。 今回の TechLunch では、曖昧だったデザインのスキルを人の思考や心理現象という視点から捉え直してみると、新しい発見があるのかも？と考え、『思考とデザインスキル』のテーマを選びました。 『早い思考』と『遅い思考』 まず最初に人の思考がどういう構造になっているか整理したいと思います。 ＊思考の捉え方には幅があるため、今回は Wikipedia で【思考】の狭義にあたる『情報処理』の内容になります。 ここで 3 つの質問を左から順に答えてください。 大抵の人であれば 2 問目までは瞬時に答えが出たと思います。3 問目はどうでしょうか？ 3 問目は他よりも時間がかかったかと思います。情報を処理するときの思考には 1 問目と 2 問目のように瞬時に答えれるのは『 早い思考 』、3 問目のように少し時間は必要な『 遅い思考 』の 2 つがあります。 行動経済学では、この早い思考を『 システム 1 』、遅い思考を『 システム 2 』と呼んでいます。 システム 1 は、自動的に直感で動く では次にこちらをご覧ください。 どちらの直線が長いでしょうか？答えはどちらも同じです。この問題をご存知の方でも見た瞬間は A が長く見えるのではないでしょうか？ ではこちらではどうでしょうか？ こちらの文字をみたときに、海水浴していて溺れている、もしくはそれに近いシーンを思い浮かべてないでしょうか？　この二語のあいだには『りんご　あまい』というような直接の相関はありません。それにもかかわらず出来れば避けたくなるようなことでも無意識に関連づけられ、シーンが思い浮かんだはずです。 システム 1 には、さきほどの直線の長さのように間違っていたとしても『 見たまま 』を認識する機能と 2 つの文字から『 関連づけ 』をおこないストーリーを組み立てる機能があります。そのどちらもが自分の意識とは関係なく自動で、しかも強力に働いています。 システム 2 は、手動で論理的に動く 最初の二桁の掛け算を思い出してください。日本で算数を学んだ人であれば、二桁の掛け算のとき『考える』段階に移ると思います。これがシステム 2 のスイッチです。システム 1 は常時スイッチが入っていてほぼ自動で答えを出しますが、システム 2 は意識的に『考える』というステップを踏まないと動きません。システム 1 は自動ですが、システム 2 は手動です。 手動のため手間かかりますが、システム 1 にはない用心深さと慎重さがあります。こちらの問題をご覧ください。 『 バットとボールで 110 円、バットはボールより 100 円高い、ボールの値段は？ 』 即答で答えた人は 10 円と答える方が多いようです。こういう問題にはシステム 2 がうってつけで、論理的かつ正確に答えを出そうとします。答えは 5 円です。なかには頭の回転が早く即答できる人がいらっしゃることだと思います。そんな方にはこちらの問題を答えていだだきましょう。 3 日前から食べた夕飯の献立を口に出して発表しながら、『26x673』『245x287』『346x4546』の 3 問を 90 秒以内に解答してください。 いかがでしょうか？システム 2 は手動でうごき論理的で正確に答え出そうとしますが、複雑すぎる演算やマルチタスクにめっぽう弱くスタミナもありません。あきらめて電卓を叩いた方は、システム 2 がギブアップしたということかもしれません。 システム 1 と 2 の特徴は以下。どちらも良いところとそうでないところがあります。 デザインを再構築 これらシステム 1&2 の特性を踏まえた上で簡単なニュース記事のタイポグラフィを整理してみました。 発表資料の 58 ページからご覧ください。 speakerdeck.com こと細かく情報をシステム 1&2 のフィルターを通すことで、タイトルやリード、本文の行間、文字サイズ、それらがシステム 2 が情報を理解しやすくするための１つ機能として捉えることができます。当たり前に使っていたスキルや機能を別の視点で捉えることで違った深い意味を見出せるようになり、大きな発見につながりました。 今回はタイポグラフィだったのでシステム 2 寄りのものでしたが、ビジュアルアイデンティティが強く抽象的なデザインは、意図的にシステム 2 を封じ込めシステム 1 の直感性を利用して内容を理解してもらうこともできます。 システム 1&2 の 2 つの特性を踏まえて使いこなすことで、スキルの深い理解はもちろんですが、感覚とは違うデザインの伝え方の新しいヒントにもなりそうです。 さいごに YouTube や Instagram、LINE はどちらかというと直感性を促すシステム 1 が活躍するアプリです。それだけでなく身の回りにあるサービス全体がその傾向という印象をうけます。システム 1 は普段からスイッチが入っているため、比較的に簡易なステップで働きかけることができます。 一方でシステム 2 は複雑な演算には耐えれず、しっかりとケアしながらでないと十分な運用ができません。ただケアをしっかりすると恩恵も大きいといえます。 金融、教育、雇用、そして医療と、20 年前とは比較にならないほどインターネットは人生の節目に深く関わるようになったからです。人生に関わる選択をネットで行うとき、 直感だけでなくシステム 2 を働かせて熟考し納得のいく決断を行うことが、よりユーザーの利益につながる と私は考えています。 メドレーで提供しているサービスはユーザーの人生に少なからず関わる性質をもっています。すぐに結論づけしてもらうより、ユーザーにとって正しいと思える判断ができるように、 システム 2 をうまく働かせることができる環境をデザイナーとしてつくっていきたい と思います。 おまけ 今回のテックランチで参考にさせていただいた書籍は以下のものになります。 『 ファスト＆スロー（上・下） 』ダニエル・カーネマン 『 予想通りに不合理 』ダン・アリエリ 『 錯覚の科学 』クリストファー・チャブルス＆ダニエル・シモンズ 『 UI デザインの心理学 』ジェフ・ジョンソン 今回のお話は、本当に本当に表面の部分になります。流し読みでも参考になるので手に取って見てください。またこういうことに興味がわいたデザイナーさん・エンジニアさん、是非是非メドレーに遊びに来てください！（絶賛募集中です！） お知らせ メドレーでは、ジョブメドレーだけでなく、医師たちがつくるオンライン医療事典「 MEDLEY 」やオンライン診療アプリ「 CLINICS 」、口コミで探せる介護施設の検索サイト「 介護のほんね 」などのプロダクトも提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。 www.medley.jp 今後ともメドレーを、よろしくお願いいたします！

はじめまして！最近みるみる太りだしてはいるものの、まだ機は熟していないとダイエットの時期をぐっと堪えている開発本部イケメン担当のデザイナー・小山です。 メドレーでは TechLunch という社内勉強会を実施しているのですが、 前田 に引き続き私も発表する機会をいただきましたので、その内容を紹介させていただきます。テーマは「思考とデザインスキル」です。発表資料は記事の最後をご覧ください。 テーマに入るまえに… みなさん『黄金比』ってご存知ですか？ 黄金比は美しいとされる物の形に共通してみられる比率で、古くから絵画や彫刻、建築などに使われています。デザイナーであれば、一度以上は使ったことあるのではないでしょうか？私もデザイナーなので何度も使っています。 ただ使ってはいるものの、なぜ美しくなるのか上手く説明ができません。当たり前のように世の中に広まっていて『困ったときの黄金比！』といった安易な思考で使っています。三十路を軽く超えたのでそれではいけないと思い、すこし調べてみました。 そもそも黄金比はエウクレイデスというユーグリッド幾何学を体系化した数学者が見つけた比率なのですが、そのとき彼は『黄金比＝美しい』とは明言していないそうです。自然物や人工物の形には一定の比率で成り立っていると考え、その比率に黄金比と名付けだけとのこと。 その後、その使いやすさから至るところで活用され、その比率に親しみが芽生え巷で受け入れられるようになりました。 認知心理学では、それを『 単純接触効果 』と呼びます。たくさん触れるうちに親しみが沸く機能が人にはもともと備わっていて、黄金比をつかったものが美しく見えるのもその影響ではないか？と言われています。この説を聞いた時、基礎的なのに原理が曖昧なデザイナーのスキルの輪郭がすこしだけハッキリしてきました。 今回の TechLunch では、曖昧だったデザインのスキルを人の思考や心理現象という視点から捉え直してみると、新しい発見があるのかも？と考え、『思考とデザインスキル』のテーマを選びました。 『早い思考』と『遅い思考』 まず最初に人の思考がどういう構造になっているか整理したいと思います。 ＊思考の捉え方には幅があるため、今回は Wikipedia で【思考】の狭義にあたる『情報処理』の内容になります。 ここで 3 つの質問を左から順に答えてください。 大抵の人であれば 2 問目までは瞬時に答えが出たと思います。3 問目はどうでしょうか？ 3 問目は他よりも時間がかかったかと思います。情報を処理するときの思考には 1 問目と 2 問目のように瞬時に答えれるのは『 早い思考 』、3 問目のように少し時間は必要な『 遅い思考 』の 2 つがあります。 行動経済学では、この早い思考を『 システム 1 』、遅い思考を『 システム 2 』と呼んでいます。 システム 1 は、自動的に直感で動く では次にこちらをご覧ください。 どちらの直線が長いでしょうか？答えはどちらも同じです。この問題をご存知の方でも見た瞬間は A が長く見えるのではないでしょうか？ ではこちらではどうでしょうか？ こちらの文字をみたときに、海水浴していて溺れている、もしくはそれに近いシーンを思い浮かべてないでしょうか？　この二語のあいだには『りんご　あまい』というような直接の相関はありません。それにもかかわらず出来れば避けたくなるようなことでも無意識に関連づけられ、シーンが思い浮かんだはずです。 システム 1 には、さきほどの直線の長さのように間違っていたとしても『 見たまま 』を認識する機能と 2 つの文字から『 関連づけ 』をおこないストーリーを組み立てる機能があります。そのどちらもが自分の意識とは関係なく自動で、しかも強力に働いています。 システム 2 は、手動で論理的に動く 最初の二桁の掛け算を思い出してください。日本で算数を学んだ人であれば、二桁の掛け算のとき『考える』段階に移ると思います。これがシステム 2 のスイッチです。システム 1 は常時スイッチが入っていてほぼ自動で答えを出しますが、システム 2 は意識的に『考える』というステップを踏まないと動きません。システム 1 は自動ですが、システム 2 は手動です。 手動のため手間かかりますが、システム 1 にはない用心深さと慎重さがあります。こちらの問題をご覧ください。 『 バットとボールで 110 円、バットはボールより 100 円高い、ボールの値段は？ 』 即答で答えた人は 10 円と答える方が多いようです。こういう問題にはシステム 2 がうってつけで、論理的かつ正確に答えを出そうとします。答えは 5 円です。なかには頭の回転が早く即答できる人がいらっしゃることだと思います。そんな方にはこちらの問題を答えていだだきましょう。 3 日前から食べた夕飯の献立を口に出して発表しながら、『26x673』『245x287』『346x4546』の 3 問を 90 秒以内に解答してください。 いかがでしょうか？システム 2 は手動でうごき論理的で正確に答え出そうとしますが、複雑すぎる演算やマルチタスクにめっぽう弱くスタミナもありません。あきらめて電卓を叩いた方は、システム 2 がギブアップしたということかもしれません。 システム 1 と 2 の特徴は以下。どちらも良いところとそうでないところがあります。 デザインを再構築 これらシステム 1&2 の特性を踏まえた上で簡単なニュース記事のタイポグラフィを整理してみました。 発表資料の 58 ページからご覧ください。 speakerdeck.com こと細かく情報をシステム 1&2 のフィルターを通すことで、タイトルやリード、本文の行間、文字サイズ、それらがシステム 2 が情報を理解しやすくするための１つ機能として捉えることができます。当たり前に使っていたスキルや機能を別の視点で捉えることで違った深い意味を見出せるようになり、大きな発見につながりました。 今回はタイポグラフィだったのでシステム 2 寄りのものでしたが、ビジュアルアイデンティティが強く抽象的なデザインは、意図的にシステム 2 を封じ込めシステム 1 の直感性を利用して内容を理解してもらうこともできます。 システム 1&2 の 2 つの特性を踏まえて使いこなすことで、スキルの深い理解はもちろんですが、感覚とは違うデザインの伝え方の新しいヒントにもなりそうです。 さいごに YouTube や Instagram、LINE はどちらかというと直感性を促すシステム 1 が活躍するアプリです。それだけでなく身の回りにあるサービス全体がその傾向という印象をうけます。システム 1 は普段からスイッチが入っているため、比較的に簡易なステップで働きかけることができます。 一方でシステム 2 は複雑な演算には耐えれず、しっかりとケアしながらでないと十分な運用ができません。ただケアをしっかりすると恩恵も大きいといえます。 金融、教育、雇用、そして医療と、20 年前とは比較にならないほどインターネットは人生の節目に深く関わるようになったからです。人生に関わる選択をネットで行うとき、 直感だけでなくシステム 2 を働かせて熟考し納得のいく決断を行うことが、よりユーザーの利益につながる と私は考えています。 メドレーで提供しているサービスはユーザーの人生に少なからず関わる性質をもっています。すぐに結論づけしてもらうより、ユーザーにとって正しいと思える判断ができるように、 システム 2 をうまく働かせることができる環境をデザイナーとしてつくっていきたい と思います。 おまけ 今回のテックランチで参考にさせていただいた書籍は以下のものになります。 『 ファスト＆スロー（上・下） 』ダニエル・カーネマン 『 予想通りに不合理 』ダン・アリエリ 『 錯覚の科学 』クリストファー・チャブルス＆ダニエル・シモンズ 『 UI デザインの心理学 』ジェフ・ジョンソン 今回のお話は、本当に本当に表面の部分になります。流し読みでも参考になるので手に取って見てください。またこういうことに興味がわいたデザイナーさん・エンジニアさん、是非是非メドレーに遊びに来てください！（絶賛募集中です！） お知らせ メドレーでは、ジョブメドレーだけでなく、医師たちがつくるオンライン医療事典「 MEDLEY 」やオンライン診療アプリ「 CLINICS 」、口コミで探せる介護施設の検索サイト「 介護のほんね 」などのプロダクトも提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。 www.medley.jp 今後ともメドレーを、よろしくお願いいたします！

はじめまして！最近みるみる太りだしてはいるものの、まだ機は熟していないとダイエットの時期をぐっと堪えている開発本部イケメン担当のデザイナー・小山です。 メドレーでは TechLunch という社内勉強会を実施しているのですが、 前田 に引き続き私も発表する機会をいただきましたので、その内容を紹介させていただきます。テーマは「思考とデザインスキル」です。発表資料は記事の最後をご覧ください。 テーマに入るまえに… みなさん『黄金比』ってご存知ですか？ 黄金比は美しいとされる物の形に共通してみられる比率で、古くから絵画や彫刻、建築などに使われています。デザイナーであれば、一度以上は使ったことあるのではないでしょうか？私もデザイナーなので何度も使っています。 ただ使ってはいるものの、なぜ美しくなるのか上手く説明ができません。当たり前のように世の中に広まっていて『困ったときの黄金比！』といった安易な思考で使っています。三十路を軽く超えたのでそれではいけないと思い、すこし調べてみました。 そもそも黄金比はエウクレイデスというユーグリッド幾何学を体系化した数学者が見つけた比率なのですが、そのとき彼は『黄金比＝美しい』とは明言していないそうです。自然物や人工物の形には一定の比率で成り立っていると考え、その比率に黄金比と名付けだけとのこと。 その後、その使いやすさから至るところで活用され、その比率に親しみが芽生え巷で受け入れられるようになりました。 認知心理学では、それを『 単純接触効果 』と呼びます。たくさん触れるうちに親しみが沸く機能が人にはもともと備わっていて、黄金比をつかったものが美しく見えるのもその影響ではないか？と言われています。この説を聞いた時、基礎的なのに原理が曖昧なデザイナーのスキルの輪郭がすこしだけハッキリしてきました。 今回の TechLunch では、曖昧だったデザインのスキルを人の思考や心理現象という視点から捉え直してみると、新しい発見があるのかも？と考え、『思考とデザインスキル』のテーマを選びました。 『早い思考』と『遅い思考』 まず最初に人の思考がどういう構造になっているか整理したいと思います。 ＊思考の捉え方には幅があるため、今回は Wikipedia で【思考】の狭義にあたる『情報処理』の内容になります。 ここで 3 つの質問を左から順に答えてください。 大抵の人であれば 2 問目までは瞬時に答えが出たと思います。3 問目はどうでしょうか？ 3 問目は他よりも時間がかかったかと思います。情報を処理するときの思考には 1 問目と 2 問目のように瞬時に答えれるのは『 早い思考 』、3 問目のように少し時間は必要な『 遅い思考 』の 2 つがあります。 行動経済学では、この早い思考を『 システム 1 』、遅い思考を『 システム 2 』と呼んでいます。 システム 1 は、自動的に直感で動く では次にこちらをご覧ください。 どちらの直線が長いでしょうか？答えはどちらも同じです。この問題をご存知の方でも見た瞬間は A が長く見えるのではないでしょうか？ ではこちらではどうでしょうか？ こちらの文字をみたときに、海水浴していて溺れている、もしくはそれに近いシーンを思い浮かべてないでしょうか？　この二語のあいだには『りんご　あまい』というような直接の相関はありません。それにもかかわらず出来れば避けたくなるようなことでも無意識に関連づけられ、シーンが思い浮かんだはずです。 システム 1 には、さきほどの直線の長さのように間違っていたとしても『 見たまま 』を認識する機能と 2 つの文字から『 関連づけ 』をおこないストーリーを組み立てる機能があります。そのどちらもが自分の意識とは関係なく自動で、しかも強力に働いています。 システム 2 は、手動で論理的に動く 最初の二桁の掛け算を思い出してください。日本で算数を学んだ人であれば、二桁の掛け算のとき『考える』段階に移ると思います。これがシステム 2 のスイッチです。システム 1 は常時スイッチが入っていてほぼ自動で答えを出しますが、システム 2 は意識的に『考える』というステップを踏まないと動きません。システム 1 は自動ですが、システム 2 は手動です。 手動のため手間かかりますが、システム 1 にはない用心深さと慎重さがあります。こちらの問題をご覧ください。 『 バットとボールで 110 円、バットはボールより 100 円高い、ボールの値段は？ 』 即答で答えた人は 10 円と答える方が多いようです。こういう問題にはシステム 2 がうってつけで、論理的かつ正確に答えを出そうとします。答えは 5 円です。なかには頭の回転が早く即答できる人がいらっしゃることだと思います。そんな方にはこちらの問題を答えていだだきましょう。 3 日前から食べた夕飯の献立を口に出して発表しながら、『26x673』『245x287』『346x4546』の 3 問を 90 秒以内に解答してください。 いかがでしょうか？システム 2 は手動でうごき論理的で正確に答え出そうとしますが、複雑すぎる演算やマルチタスクにめっぽう弱くスタミナもありません。あきらめて電卓を叩いた方は、システム 2 がギブアップしたということかもしれません。 システム 1 と 2 の特徴は以下。どちらも良いところとそうでないところがあります。 デザインを再構築 これらシステム 1&2 の特性を踏まえた上で簡単なニュース記事のタイポグラフィを整理してみました。 発表資料の 58 ページからご覧ください。 speakerdeck.com こと細かく情報をシステム 1&2 のフィルターを通すことで、タイトルやリード、本文の行間、文字サイズ、それらがシステム 2 が情報を理解しやすくするための１つ機能として捉えることができます。当たり前に使っていたスキルや機能を別の視点で捉えることで違った深い意味を見出せるようになり、大きな発見につながりました。 今回はタイポグラフィだったのでシステム 2 寄りのものでしたが、ビジュアルアイデンティティが強く抽象的なデザインは、意図的にシステム 2 を封じ込めシステム 1 の直感性を利用して内容を理解してもらうこともできます。 システム 1&2 の 2 つの特性を踏まえて使いこなすことで、スキルの深い理解はもちろんですが、感覚とは違うデザインの伝え方の新しいヒントにもなりそうです。 さいごに YouTube や Instagram、LINE はどちらかというと直感性を促すシステム 1 が活躍するアプリです。それだけでなく身の回りにあるサービス全体がその傾向という印象をうけます。システム 1 は普段からスイッチが入っているため、比較的に簡易なステップで働きかけることができます。 一方でシステム 2 は複雑な演算には耐えれず、しっかりとケアしながらでないと十分な運用ができません。ただケアをしっかりすると恩恵も大きいといえます。 金融、教育、雇用、そして医療と、20 年前とは比較にならないほどインターネットは人生の節目に深く関わるようになったからです。人生に関わる選択をネットで行うとき、 直感だけでなくシステム 2 を働かせて熟考し納得のいく決断を行うことが、よりユーザーの利益につながる と私は考えています。 メドレーで提供しているサービスはユーザーの人生に少なからず関わる性質をもっています。すぐに結論づけしてもらうより、ユーザーにとって正しいと思える判断ができるように、 システム 2 をうまく働かせることができる環境をデザイナーとしてつくっていきたい と思います。 おまけ 今回のテックランチで参考にさせていただいた書籍は以下のものになります。 『 ファスト＆スロー（上・下） 』ダニエル・カーネマン 『 予想通りに不合理 』ダン・アリエリ 『 錯覚の科学 』クリストファー・チャブルス＆ダニエル・シモンズ 『 UI デザインの心理学 』ジェフ・ジョンソン 今回のお話は、本当に本当に表面の部分になります。流し読みでも参考になるので手に取って見てください。またこういうことに興味がわいたデザイナーさん・エンジニアさん、是非是非メドレーに遊びに来てください！（絶賛募集中です！） お知らせ メドレーでは、ジョブメドレーだけでなく、医師たちがつくるオンライン医療事典「 MEDLEY 」やオンライン診療アプリ「 CLINICS 」、口コミで探せる介護施設の検索サイト「 介護のほんね 」などのプロダクトも提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。 www.medley.jp 今後ともメドレーを、よろしくお願いいたします！

はじめまして！最近みるみる太りだしてはいるものの、まだ機は熟していないとダイエットの時期をぐっと堪えている開発本部イケメン担当のデザイナー・小山です。 メドレーでは TechLunch という社内勉強会を実施しているのですが、 前田 に引き続き私も発表する機会をいただきましたので、その内容を紹介させていただきます。テーマは「思考とデザインスキル」です。発表資料は記事の最後をご覧ください。 テーマに入るまえに… みなさん『黄金比』ってご存知ですか？ 黄金比は美しいとされる物の形に共通してみられる比率で、古くから絵画や彫刻、建築などに使われています。デザイナーであれば、一度以上は使ったことあるのではないでしょうか？私もデザイナーなので何度も使っています。 ただ使ってはいるものの、なぜ美しくなるのか上手く説明ができません。当たり前のように世の中に広まっていて『困ったときの黄金比！』といった安易な思考で使っています。三十路を軽く超えたのでそれではいけないと思い、すこし調べてみました。 そもそも黄金比はエウクレイデスというユーグリッド幾何学を体系化した数学者が見つけた比率なのですが、そのとき彼は『黄金比＝美しい』とは明言していないそうです。自然物や人工物の形には一定の比率で成り立っていると考え、その比率に黄金比と名付けだけとのこと。 その後、その使いやすさから至るところで活用され、その比率に親しみが芽生え巷で受け入れられるようになりました。 認知心理学では、それを『 単純接触効果 』と呼びます。たくさん触れるうちに親しみが沸く機能が人にはもともと備わっていて、黄金比をつかったものが美しく見えるのもその影響ではないか？と言われています。この説を聞いた時、基礎的なのに原理が曖昧なデザイナーのスキルの輪郭がすこしだけハッキリしてきました。 今回の TechLunch では、曖昧だったデザインのスキルを人の思考や心理現象という視点から捉え直してみると、新しい発見があるのかも？と考え、『思考とデザインスキル』のテーマを選びました。 『早い思考』と『遅い思考』 まず最初に人の思考がどういう構造になっているか整理したいと思います。 ＊思考の捉え方には幅があるため、今回は Wikipedia で【思考】の狭義にあたる『情報処理』の内容になります。 ここで 3 つの質問を左から順に答えてください。 大抵の人であれば 2 問目までは瞬時に答えが出たと思います。3 問目はどうでしょうか？ 3 問目は他よりも時間がかかったかと思います。情報を処理するときの思考には 1 問目と 2 問目のように瞬時に答えれるのは『 早い思考 』、3 問目のように少し時間は必要な『 遅い思考 』の 2 つがあります。 行動経済学では、この早い思考を『 システム 1 』、遅い思考を『 システム 2 』と呼んでいます。 システム 1 は、自動的に直感で動く では次にこちらをご覧ください。 どちらの直線が長いでしょうか？答えはどちらも同じです。この問題をご存知の方でも見た瞬間は A が長く見えるのではないでしょうか？ ではこちらではどうでしょうか？ こちらの文字をみたときに、海水浴していて溺れている、もしくはそれに近いシーンを思い浮かべてないでしょうか？　この二語のあいだには『りんご　あまい』というような直接の相関はありません。それにもかかわらず出来れば避けたくなるようなことでも無意識に関連づけられ、シーンが思い浮かんだはずです。 システム 1 には、さきほどの直線の長さのように間違っていたとしても『 見たまま 』を認識する機能と 2 つの文字から『 関連づけ 』をおこないストーリーを組み立てる機能があります。そのどちらもが自分の意識とは関係なく自動で、しかも強力に働いています。 システム 2 は、手動で論理的に動く 最初の二桁の掛け算を思い出してください。日本で算数を学んだ人であれば、二桁の掛け算のとき『考える』段階に移ると思います。これがシステム 2 のスイッチです。システム 1 は常時スイッチが入っていてほぼ自動で答えを出しますが、システム 2 は意識的に『考える』というステップを踏まないと動きません。システム 1 は自動ですが、システム 2 は手動です。 手動のため手間かかりますが、システム 1 にはない用心深さと慎重さがあります。こちらの問題をご覧ください。 『 バットとボールで 110 円、バットはボールより 100 円高い、ボールの値段は？ 』 即答で答えた人は 10 円と答える方が多いようです。こういう問題にはシステム 2 がうってつけで、論理的かつ正確に答えを出そうとします。答えは 5 円です。なかには頭の回転が早く即答できる人がいらっしゃることだと思います。そんな方にはこちらの問題を答えていだだきましょう。 3 日前から食べた夕飯の献立を口に出して発表しながら、『26x673』『245x287』『346x4546』の 3 問を 90 秒以内に解答してください。 いかがでしょうか？システム 2 は手動でうごき論理的で正確に答え出そうとしますが、複雑すぎる演算やマルチタスクにめっぽう弱くスタミナもありません。あきらめて電卓を叩いた方は、システム 2 がギブアップしたということかもしれません。 システム 1 と 2 の特徴は以下。どちらも良いところとそうでないところがあります。 デザインを再構築 これらシステム 1&2 の特性を踏まえた上で簡単なニュース記事のタイポグラフィを整理してみました。 発表資料の 58 ページからご覧ください。 speakerdeck.com こと細かく情報をシステム 1&2 のフィルターを通すことで、タイトルやリード、本文の行間、文字サイズ、それらがシステム 2 が情報を理解しやすくするための１つ機能として捉えることができます。当たり前に使っていたスキルや機能を別の視点で捉えることで違った深い意味を見出せるようになり、大きな発見につながりました。 今回はタイポグラフィだったのでシステム 2 寄りのものでしたが、ビジュアルアイデンティティが強く抽象的なデザインは、意図的にシステム 2 を封じ込めシステム 1 の直感性を利用して内容を理解してもらうこともできます。 システム 1&2 の 2 つの特性を踏まえて使いこなすことで、スキルの深い理解はもちろんですが、感覚とは違うデザインの伝え方の新しいヒントにもなりそうです。 さいごに YouTube や Instagram、LINE はどちらかというと直感性を促すシステム 1 が活躍するアプリです。それだけでなく身の回りにあるサービス全体がその傾向という印象をうけます。システム 1 は普段からスイッチが入っているため、比較的に簡易なステップで働きかけることができます。 一方でシステム 2 は複雑な演算には耐えれず、しっかりとケアしながらでないと十分な運用ができません。ただケアをしっかりすると恩恵も大きいといえます。 金融、教育、雇用、そして医療と、20 年前とは比較にならないほどインターネットは人生の節目に深く関わるようになったからです。人生に関わる選択をネットで行うとき、 直感だけでなくシステム 2 を働かせて熟考し納得のいく決断を行うことが、よりユーザーの利益につながる と私は考えています。 メドレーで提供しているサービスはユーザーの人生に少なからず関わる性質をもっています。すぐに結論づけしてもらうより、ユーザーにとって正しいと思える判断ができるように、 システム 2 をうまく働かせることができる環境をデザイナーとしてつくっていきたい と思います。 おまけ 今回のテックランチで参考にさせていただいた書籍は以下のものになります。 『 ファスト＆スロー（上・下） 』ダニエル・カーネマン 『 予想通りに不合理 』ダン・アリエリ 『 錯覚の科学 』クリストファー・チャブルス＆ダニエル・シモンズ 『 UI デザインの心理学 』ジェフ・ジョンソン 今回のお話は、本当に本当に表面の部分になります。流し読みでも参考になるので手に取って見てください。またこういうことに興味がわいたデザイナーさん・エンジニアさん、是非是非メドレーに遊びに来てください！（絶賛募集中です！） お知らせ メドレーでは、ジョブメドレーだけでなく、医師たちがつくるオンライン医療事典「 MEDLEY 」やオンライン診療アプリ「 CLINICS 」、口コミで探せる介護施設の検索サイト「 介護のほんね 」などのプロダクトも提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。 www.medley.jp 今後ともメドレーを、よろしくお願いいたします！

はじめまして！最近みるみる太りだしてはいるものの、まだ機は熟していないとダイエットの時期をぐっと堪えている開発本部イケメン担当のデザイナー・小山です。 メドレーでは TechLunch という社内勉強会を実施しているのですが、 前田 に引き続き私も発表する機会をいただきましたので、その内容を紹介させていただきます。テーマは「思考とデザインスキル」です。発表資料は記事の最後をご覧ください。 テーマに入るまえに… みなさん『黄金比』ってご存知ですか？ 黄金比は美しいとされる物の形に共通してみられる比率で、古くから絵画や彫刻、建築などに使われています。デザイナーであれば、一度以上は使ったことあるのではないでしょうか？私もデザイナーなので何度も使っています。 ただ使ってはいるものの、なぜ美しくなるのか上手く説明ができません。当たり前のように世の中に広まっていて『困ったときの黄金比！』といった安易な思考で使っています。三十路を軽く超えたのでそれではいけないと思い、すこし調べてみました。 そもそも黄金比はエウクレイデスというユーグリッド幾何学を体系化した数学者が見つけた比率なのですが、そのとき彼は『黄金比＝美しい』とは明言していないそうです。自然物や人工物の形には一定の比率で成り立っていると考え、その比率に黄金比と名付けだけとのこと。 その後、その使いやすさから至るところで活用され、その比率に親しみが芽生え巷で受け入れられるようになりました。 認知心理学では、それを『 単純接触効果 』と呼びます。たくさん触れるうちに親しみが沸く機能が人にはもともと備わっていて、黄金比をつかったものが美しく見えるのもその影響ではないか？と言われています。この説を聞いた時、基礎的なのに原理が曖昧なデザイナーのスキルの輪郭がすこしだけハッキリしてきました。 今回の TechLunch では、曖昧だったデザインのスキルを人の思考や心理現象という視点から捉え直してみると、新しい発見があるのかも？と考え、『思考とデザインスキル』のテーマを選びました。 『早い思考』と『遅い思考』 まず最初に人の思考がどういう構造になっているか整理したいと思います。 ＊思考の捉え方には幅があるため、今回は Wikipedia で【思考】の狭義にあたる『情報処理』の内容になります。 ここで 3 つの質問を左から順に答えてください。 大抵の人であれば 2 問目までは瞬時に答えが出たと思います。3 問目はどうでしょうか？ 3 問目は他よりも時間がかかったかと思います。情報を処理するときの思考には 1 問目と 2 問目のように瞬時に答えれるのは『 早い思考 』、3 問目のように少し時間は必要な『 遅い思考 』の 2 つがあります。 行動経済学では、この早い思考を『 システム 1 』、遅い思考を『 システム 2 』と呼んでいます。 システム 1 は、自動的に直感で動く では次にこちらをご覧ください。 どちらの直線が長いでしょうか？答えはどちらも同じです。この問題をご存知の方でも見た瞬間は A が長く見えるのではないでしょうか？ ではこちらではどうでしょうか？ こちらの文字をみたときに、海水浴していて溺れている、もしくはそれに近いシーンを思い浮かべてないでしょうか？　この二語のあいだには『りんご　あまい』というような直接の相関はありません。それにもかかわらず出来れば避けたくなるようなことでも無意識に関連づけられ、シーンが思い浮かんだはずです。 システム 1 には、さきほどの直線の長さのように間違っていたとしても『 見たまま 』を認識する機能と 2 つの文字から『 関連づけ 』をおこないストーリーを組み立てる機能があります。そのどちらもが自分の意識とは関係なく自動で、しかも強力に働いています。 システム 2 は、手動で論理的に動く 最初の二桁の掛け算を思い出してください。日本で算数を学んだ人であれば、二桁の掛け算のとき『考える』段階に移ると思います。これがシステム 2 のスイッチです。システム 1 は常時スイッチが入っていてほぼ自動で答えを出しますが、システム 2 は意識的に『考える』というステップを踏まないと動きません。システム 1 は自動ですが、システム 2 は手動です。 手動のため手間かかりますが、システム 1 にはない用心深さと慎重さがあります。こちらの問題をご覧ください。 『 バットとボールで 110 円、バットはボールより 100 円高い、ボールの値段は？ 』 即答で答えた人は 10 円と答える方が多いようです。こういう問題にはシステム 2 がうってつけで、論理的かつ正確に答えを出そうとします。答えは 5 円です。なかには頭の回転が早く即答できる人がいらっしゃることだと思います。そんな方にはこちらの問題を答えていだだきましょう。 3 日前から食べた夕飯の献立を口に出して発表しながら、『26x673』『245x287』『346x4546』の 3 問を 90 秒以内に解答してください。 いかがでしょうか？システム 2 は手動でうごき論理的で正確に答え出そうとしますが、複雑すぎる演算やマルチタスクにめっぽう弱くスタミナもありません。あきらめて電卓を叩いた方は、システム 2 がギブアップしたということかもしれません。 システム 1 と 2 の特徴は以下。どちらも良いところとそうでないところがあります。 デザインを再構築 これらシステム 1&2 の特性を踏まえた上で簡単なニュース記事のタイポグラフィを整理してみました。 発表資料の 58 ページからご覧ください。 speakerdeck.com こと細かく情報をシステム 1&2 のフィルターを通すことで、タイトルやリード、本文の行間、文字サイズ、それらがシステム 2 が情報を理解しやすくするための１つ機能として捉えることができます。当たり前に使っていたスキルや機能を別の視点で捉えることで違った深い意味を見出せるようになり、大きな発見につながりました。 今回はタイポグラフィだったのでシステム 2 寄りのものでしたが、ビジュアルアイデンティティが強く抽象的なデザインは、意図的にシステム 2 を封じ込めシステム 1 の直感性を利用して内容を理解してもらうこともできます。 システム 1&2 の 2 つの特性を踏まえて使いこなすことで、スキルの深い理解はもちろんですが、感覚とは違うデザインの伝え方の新しいヒントにもなりそうです。 さいごに YouTube や Instagram、LINE はどちらかというと直感性を促すシステム 1 が活躍するアプリです。それだけでなく身の回りにあるサービス全体がその傾向という印象をうけます。システム 1 は普段からスイッチが入っているため、比較的に簡易なステップで働きかけることができます。 一方でシステム 2 は複雑な演算には耐えれず、しっかりとケアしながらでないと十分な運用ができません。ただケアをしっかりすると恩恵も大きいといえます。 金融、教育、雇用、そして医療と、20 年前とは比較にならないほどインターネットは人生の節目に深く関わるようになったからです。人生に関わる選択をネットで行うとき、 直感だけでなくシステム 2 を働かせて熟考し納得のいく決断を行うことが、よりユーザーの利益につながる と私は考えています。 メドレーで提供しているサービスはユーザーの人生に少なからず関わる性質をもっています。すぐに結論づけしてもらうより、ユーザーにとって正しいと思える判断ができるように、 システム 2 をうまく働かせることができる環境をデザイナーとしてつくっていきたい と思います。 おまけ 今回のテックランチで参考にさせていただいた書籍は以下のものになります。 『 ファスト＆スロー（上・下） 』ダニエル・カーネマン 『 予想通りに不合理 』ダン・アリエリ 『 錯覚の科学 』クリストファー・チャブルス＆ダニエル・シモンズ 『 UI デザインの心理学 』ジェフ・ジョンソン 今回のお話は、本当に本当に表面の部分になります。流し読みでも参考になるので手に取って見てください。またこういうことに興味がわいたデザイナーさん・エンジニアさん、是非是非メドレーに遊びに来てください！（絶賛募集中です！） お知らせ メドレーでは、ジョブメドレーだけでなく、医師たちがつくるオンライン医療事典「 MEDLEY 」やオンライン診療アプリ「 CLINICS 」、口コミで探せる介護施設の検索サイト「 介護のほんね 」などのプロダクトも提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。 www.medley.jp 今後ともメドレーを、よろしくお願いいたします！

はじめまして！最近みるみる太りだしてはいるものの、まだ機は熟していないとダイエットの時期をぐっと堪えている開発本部イケメン担当のデザイナー・小山です。 メドレーでは TechLunch という社内勉強会を実施しているのですが、 前田 に引き続き私も発表する機会をいただきましたので、その内容を紹介させていただきます。テーマは「思考とデザインスキル」です。発表資料は記事の最後をご覧ください。 テーマに入るまえに… みなさん『黄金比』ってご存知ですか？ 黄金比は美しいとされる物の形に共通してみられる比率で、古くから絵画や彫刻、建築などに使われています。デザイナーであれば、一度以上は使ったことあるのではないでしょうか？私もデザイナーなので何度も使っています。 ただ使ってはいるものの、なぜ美しくなるのか上手く説明ができません。当たり前のように世の中に広まっていて『困ったときの黄金比！』といった安易な思考で使っています。三十路を軽く超えたのでそれではいけないと思い、すこし調べてみました。 そもそも黄金比はエウクレイデスというユーグリッド幾何学を体系化した数学者が見つけた比率なのですが、そのとき彼は『黄金比＝美しい』とは明言していないそうです。自然物や人工物の形には一定の比率で成り立っていると考え、その比率に黄金比と名付けだけとのこと。 その後、その使いやすさから至るところで活用され、その比率に親しみが芽生え巷で受け入れられるようになりました。 認知心理学では、それを『 単純接触効果 』と呼びます。たくさん触れるうちに親しみが沸く機能が人にはもともと備わっていて、黄金比をつかったものが美しく見えるのもその影響ではないか？と言われています。この説を聞いた時、基礎的なのに原理が曖昧なデザイナーのスキルの輪郭がすこしだけハッキリしてきました。 今回の TechLunch では、曖昧だったデザインのスキルを人の思考や心理現象という視点から捉え直してみると、新しい発見があるのかも？と考え、『思考とデザインスキル』のテーマを選びました。 『早い思考』と『遅い思考』 まず最初に人の思考がどういう構造になっているか整理したいと思います。 ＊思考の捉え方には幅があるため、今回は Wikipedia で【思考】の狭義にあたる『情報処理』の内容になります。 ここで 3 つの質問を左から順に答えてください。 大抵の人であれば 2 問目までは瞬時に答えが出たと思います。3 問目はどうでしょうか？ 3 問目は他よりも時間がかかったかと思います。情報を処理するときの思考には 1 問目と 2 問目のように瞬時に答えれるのは『 早い思考 』、3 問目のように少し時間は必要な『 遅い思考 』の 2 つがあります。 行動経済学では、この早い思考を『 システム 1 』、遅い思考を『 システム 2 』と呼んでいます。 システム 1 は、自動的に直感で動く では次にこちらをご覧ください。 どちらの直線が長いでしょうか？答えはどちらも同じです。この問題をご存知の方でも見た瞬間は A が長く見えるのではないでしょうか？ ではこちらではどうでしょうか？ こちらの文字をみたときに、海水浴していて溺れている、もしくはそれに近いシーンを思い浮かべてないでしょうか？　この二語のあいだには『りんご　あまい』というような直接の相関はありません。それにもかかわらず出来れば避けたくなるようなことでも無意識に関連づけられ、シーンが思い浮かんだはずです。 システム 1 には、さきほどの直線の長さのように間違っていたとしても『 見たまま 』を認識する機能と 2 つの文字から『 関連づけ 』をおこないストーリーを組み立てる機能があります。そのどちらもが自分の意識とは関係なく自動で、しかも強力に働いています。 システム 2 は、手動で論理的に動く 最初の二桁の掛け算を思い出してください。日本で算数を学んだ人であれば、二桁の掛け算のとき『考える』段階に移ると思います。これがシステム 2 のスイッチです。システム 1 は常時スイッチが入っていてほぼ自動で答えを出しますが、システム 2 は意識的に『考える』というステップを踏まないと動きません。システム 1 は自動ですが、システム 2 は手動です。 手動のため手間かかりますが、システム 1 にはない用心深さと慎重さがあります。こちらの問題をご覧ください。 『 バットとボールで 110 円、バットはボールより 100 円高い、ボールの値段は？ 』 即答で答えた人は 10 円と答える方が多いようです。こういう問題にはシステム 2 がうってつけで、論理的かつ正確に答えを出そうとします。答えは 5 円です。なかには頭の回転が早く即答できる人がいらっしゃることだと思います。そんな方にはこちらの問題を答えていだだきましょう。 3 日前から食べた夕飯の献立を口に出して発表しながら、『26x673』『245x287』『346x4546』の 3 問を 90 秒以内に解答してください。 いかがでしょうか？システム 2 は手動でうごき論理的で正確に答え出そうとしますが、複雑すぎる演算やマルチタスクにめっぽう弱くスタミナもありません。あきらめて電卓を叩いた方は、システム 2 がギブアップしたということかもしれません。 システム 1 と 2 の特徴は以下。どちらも良いところとそうでないところがあります。 デザインを再構築 これらシステム 1&2 の特性を踏まえた上で簡単なニュース記事のタイポグラフィを整理してみました。 発表資料の 58 ページからご覧ください。 speakerdeck.com こと細かく情報をシステム 1&2 のフィルターを通すことで、タイトルやリード、本文の行間、文字サイズ、それらがシステム 2 が情報を理解しやすくするための１つ機能として捉えることができます。当たり前に使っていたスキルや機能を別の視点で捉えることで違った深い意味を見出せるようになり、大きな発見につながりました。 今回はタイポグラフィだったのでシステム 2 寄りのものでしたが、ビジュアルアイデンティティが強く抽象的なデザインは、意図的にシステム 2 を封じ込めシステム 1 の直感性を利用して内容を理解してもらうこともできます。 システム 1&2 の 2 つの特性を踏まえて使いこなすことで、スキルの深い理解はもちろんですが、感覚とは違うデザインの伝え方の新しいヒントにもなりそうです。 さいごに YouTube や Instagram、LINE はどちらかというと直感性を促すシステム 1 が活躍するアプリです。それだけでなく身の回りにあるサービス全体がその傾向という印象をうけます。システム 1 は普段からスイッチが入っているため、比較的に簡易なステップで働きかけることができます。 一方でシステム 2 は複雑な演算には耐えれず、しっかりとケアしながらでないと十分な運用ができません。ただケアをしっかりすると恩恵も大きいといえます。 金融、教育、雇用、そして医療と、20 年前とは比較にならないほどインターネットは人生の節目に深く関わるようになったからです。人生に関わる選択をネットで行うとき、 直感だけでなくシステム 2 を働かせて熟考し納得のいく決断を行うことが、よりユーザーの利益につながる と私は考えています。 メドレーで提供しているサービスはユーザーの人生に少なからず関わる性質をもっています。すぐに結論づけしてもらうより、ユーザーにとって正しいと思える判断ができるように、 システム 2 をうまく働かせることができる環境をデザイナーとしてつくっていきたい と思います。 おまけ 今回のテックランチで参考にさせていただいた書籍は以下のものになります。 『 ファスト＆スロー（上・下） 』ダニエル・カーネマン 『 予想通りに不合理 』ダン・アリエリ 『 錯覚の科学 』クリストファー・チャブルス＆ダニエル・シモンズ 『 UI デザインの心理学 』ジェフ・ジョンソン 今回のお話は、本当に本当に表面の部分になります。流し読みでも参考になるので手に取って見てください。またこういうことに興味がわいたデザイナーさん・エンジニアさん、是非是非メドレーに遊びに来てください！（絶賛募集中です！） お知らせ メドレーでは、ジョブメドレーだけでなく、医師たちがつくるオンライン医療事典「 MEDLEY 」やオンライン診療アプリ「 CLINICS 」、口コミで探せる介護施設の検索サイト「 介護のほんね 」などのプロダクトも提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。 www.medley.jp 今後ともメドレーを、よろしくお願いいたします！

はじめまして！最近みるみる太りだしてはいるものの、まだ機は熟していないとダイエットの時期をぐっと堪えている開発本部イケメン担当のデザイナー・小山です。 メドレーでは TechLunch という社内勉強会を実施しているのですが、 前田 に引き続き私も発表する機会をいただきましたので、その内容を紹介させていただきます。テーマは「思考とデザインスキル」です。発表資料は記事の最後をご覧ください。 テーマに入るまえに… みなさん『黄金比』ってご存知ですか？ 黄金比は美しいとされる物の形に共通してみられる比率で、古くから絵画や彫刻、建築などに使われています。デザイナーであれば、一度以上は使ったことあるのではないでしょうか？私もデザイナーなので何度も使っています。 ただ使ってはいるものの、なぜ美しくなるのか上手く説明ができません。当たり前のように世の中に広まっていて『困ったときの黄金比！』といった安易な思考で使っています。三十路を軽く超えたのでそれではいけないと思い、すこし調べてみました。 そもそも黄金比はエウクレイデスというユーグリッド幾何学を体系化した数学者が見つけた比率なのですが、そのとき彼は『黄金比＝美しい』とは明言していないそうです。自然物や人工物の形には一定の比率で成り立っていると考え、その比率に黄金比と名付けだけとのこと。 その後、その使いやすさから至るところで活用され、その比率に親しみが芽生え巷で受け入れられるようになりました。 認知心理学では、それを『 単純接触効果 』と呼びます。たくさん触れるうちに親しみが沸く機能が人にはもともと備わっていて、黄金比をつかったものが美しく見えるのもその影響ではないか？と言われています。この説を聞いた時、基礎的なのに原理が曖昧なデザイナーのスキルの輪郭がすこしだけハッキリしてきました。 今回の TechLunch では、曖昧だったデザインのスキルを人の思考や心理現象という視点から捉え直してみると、新しい発見があるのかも？と考え、『思考とデザインスキル』のテーマを選びました。 『早い思考』と『遅い思考』 まず最初に人の思考がどういう構造になっているか整理したいと思います。 ＊思考の捉え方には幅があるため、今回は Wikipedia で【思考】の狭義にあたる『情報処理』の内容になります。 ここで 3 つの質問を左から順に答えてください。 大抵の人であれば 2 問目までは瞬時に答えが出たと思います。3 問目はどうでしょうか？ 3 問目は他よりも時間がかかったかと思います。情報を処理するときの思考には 1 問目と 2 問目のように瞬時に答えれるのは『 早い思考 』、3 問目のように少し時間は必要な『 遅い思考 』の 2 つがあります。 行動経済学では、この早い思考を『 システム 1 』、遅い思考を『 システム 2 』と呼んでいます。 システム 1 は、自動的に直感で動く では次にこちらをご覧ください。 どちらの直線が長いでしょうか？答えはどちらも同じです。この問題をご存知の方でも見た瞬間は A が長く見えるのではないでしょうか？ ではこちらではどうでしょうか？ こちらの文字をみたときに、海水浴していて溺れている、もしくはそれに近いシーンを思い浮かべてないでしょうか？　この二語のあいだには『りんご　あまい』というような直接の相関はありません。それにもかかわらず出来れば避けたくなるようなことでも無意識に関連づけられ、シーンが思い浮かんだはずです。 システム 1 には、さきほどの直線の長さのように間違っていたとしても『 見たまま 』を認識する機能と 2 つの文字から『 関連づけ 』をおこないストーリーを組み立てる機能があります。そのどちらもが自分の意識とは関係なく自動で、しかも強力に働いています。 システム 2 は、手動で論理的に動く 最初の二桁の掛け算を思い出してください。日本で算数を学んだ人であれば、二桁の掛け算のとき『考える』段階に移ると思います。これがシステム 2 のスイッチです。システム 1 は常時スイッチが入っていてほぼ自動で答えを出しますが、システム 2 は意識的に『考える』というステップを踏まないと動きません。システム 1 は自動ですが、システム 2 は手動です。 手動のため手間かかりますが、システム 1 にはない用心深さと慎重さがあります。こちらの問題をご覧ください。 『 バットとボールで 110 円、バットはボールより 100 円高い、ボールの値段は？ 』 即答で答えた人は 10 円と答える方が多いようです。こういう問題にはシステム 2 がうってつけで、論理的かつ正確に答えを出そうとします。答えは 5 円です。なかには頭の回転が早く即答できる人がいらっしゃることだと思います。そんな方にはこちらの問題を答えていだだきましょう。 3 日前から食べた夕飯の献立を口に出して発表しながら、『26x673』『245x287』『346x4546』の 3 問を 90 秒以内に解答してください。 いかがでしょうか？システム 2 は手動でうごき論理的で正確に答え出そうとしますが、複雑すぎる演算やマルチタスクにめっぽう弱くスタミナもありません。あきらめて電卓を叩いた方は、システム 2 がギブアップしたということかもしれません。 システム 1 と 2 の特徴は以下。どちらも良いところとそうでないところがあります。 デザインを再構築 これらシステム 1&2 の特性を踏まえた上で簡単なニュース記事のタイポグラフィを整理してみました。 発表資料の 58 ページからご覧ください。 speakerdeck.com こと細かく情報をシステム 1&2 のフィルターを通すことで、タイトルやリード、本文の行間、文字サイズ、それらがシステム 2 が情報を理解しやすくするための１つ機能として捉えることができます。当たり前に使っていたスキルや機能を別の視点で捉えることで違った深い意味を見出せるようになり、大きな発見につながりました。 今回はタイポグラフィだったのでシステム 2 寄りのものでしたが、ビジュアルアイデンティティが強く抽象的なデザインは、意図的にシステム 2 を封じ込めシステム 1 の直感性を利用して内容を理解してもらうこともできます。 システム 1&2 の 2 つの特性を踏まえて使いこなすことで、スキルの深い理解はもちろんですが、感覚とは違うデザインの伝え方の新しいヒントにもなりそうです。 さいごに YouTube や Instagram、LINE はどちらかというと直感性を促すシステム 1 が活躍するアプリです。それだけでなく身の回りにあるサービス全体がその傾向という印象をうけます。システム 1 は普段からスイッチが入っているため、比較的に簡易なステップで働きかけることができます。 一方でシステム 2 は複雑な演算には耐えれず、しっかりとケアしながらでないと十分な運用ができません。ただケアをしっかりすると恩恵も大きいといえます。 金融、教育、雇用、そして医療と、20 年前とは比較にならないほどインターネットは人生の節目に深く関わるようになったからです。人生に関わる選択をネットで行うとき、 直感だけでなくシステム 2 を働かせて熟考し納得のいく決断を行うことが、よりユーザーの利益につながる と私は考えています。 メドレーで提供しているサービスはユーザーの人生に少なからず関わる性質をもっています。すぐに結論づけしてもらうより、ユーザーにとって正しいと思える判断ができるように、 システム 2 をうまく働かせることができる環境をデザイナーとしてつくっていきたい と思います。 おまけ 今回のテックランチで参考にさせていただいた書籍は以下のものになります。 『 ファスト＆スロー（上・下） 』ダニエル・カーネマン 『 予想通りに不合理 』ダン・アリエリ 『 錯覚の科学 』クリストファー・チャブルス＆ダニエル・シモンズ 『 UI デザインの心理学 』ジェフ・ジョンソン 今回のお話は、本当に本当に表面の部分になります。流し読みでも参考になるので手に取って見てください。またこういうことに興味がわいたデザイナーさん・エンジニアさん、是非是非メドレーに遊びに来てください！（絶賛募集中です！） お知らせ メドレーでは、ジョブメドレーだけでなく、医師たちがつくるオンライン医療事典「 MEDLEY 」やオンライン診療アプリ「 CLINICS 」、口コミで探せる介護施設の検索サイト「 介護のほんね 」などのプロダクトも提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。 www.medley.jp 今後ともメドレーを、よろしくお願いいたします！

はじめまして！最近みるみる太りだしてはいるものの、まだ機は熟していないとダイエットの時期をぐっと堪えている開発本部イケメン担当のデザイナー・小山です。 メドレーでは TechLunch という社内勉強会を実施しているのですが、 前田 に引き続き私も発表する機会をいただきましたので、その内容を紹介させていただきます。テーマは「思考とデザインスキル」です。発表資料は記事の最後をご覧ください。 テーマに入るまえに… みなさん『黄金比』ってご存知ですか？ 黄金比は美しいとされる物の形に共通してみられる比率で、古くから絵画や彫刻、建築などに使われています。デザイナーであれば、一度以上は使ったことあるのではないでしょうか？私もデザイナーなので何度も使っています。 ただ使ってはいるものの、なぜ美しくなるのか上手く説明ができません。当たり前のように世の中に広まっていて『困ったときの黄金比！』といった安易な思考で使っています。三十路を軽く超えたのでそれではいけないと思い、すこし調べてみました。 そもそも黄金比はエウクレイデスというユーグリッド幾何学を体系化した数学者が見つけた比率なのですが、そのとき彼は『黄金比＝美しい』とは明言していないそうです。自然物や人工物の形には一定の比率で成り立っていると考え、その比率に黄金比と名付けだけとのこと。 その後、その使いやすさから至るところで活用され、その比率に親しみが芽生え巷で受け入れられるようになりました。 認知心理学では、それを『 単純接触効果 』と呼びます。たくさん触れるうちに親しみが沸く機能が人にはもともと備わっていて、黄金比をつかったものが美しく見えるのもその影響ではないか？と言われています。この説を聞いた時、基礎的なのに原理が曖昧なデザイナーのスキルの輪郭がすこしだけハッキリしてきました。 今回の TechLunch では、曖昧だったデザインのスキルを人の思考や心理現象という視点から捉え直してみると、新しい発見があるのかも？と考え、『思考とデザインスキル』のテーマを選びました。 『早い思考』と『遅い思考』 まず最初に人の思考がどういう構造になっているか整理したいと思います。 ＊思考の捉え方には幅があるため、今回は Wikipedia で【思考】の狭義にあたる『情報処理』の内容になります。 ここで 3 つの質問を左から順に答えてください。 大抵の人であれば 2 問目までは瞬時に答えが出たと思います。3 問目はどうでしょうか？ 3 問目は他よりも時間がかかったかと思います。情報を処理するときの思考には 1 問目と 2 問目のように瞬時に答えれるのは『 早い思考 』、3 問目のように少し時間は必要な『 遅い思考 』の 2 つがあります。 行動経済学では、この早い思考を『 システム 1 』、遅い思考を『 システム 2 』と呼んでいます。 システム 1 は、自動的に直感で動く では次にこちらをご覧ください。 どちらの直線が長いでしょうか？答えはどちらも同じです。この問題をご存知の方でも見た瞬間は A が長く見えるのではないでしょうか？ ではこちらではどうでしょうか？ こちらの文字をみたときに、海水浴していて溺れている、もしくはそれに近いシーンを思い浮かべてないでしょうか？　この二語のあいだには『りんご　あまい』というような直接の相関はありません。それにもかかわらず出来れば避けたくなるようなことでも無意識に関連づけられ、シーンが思い浮かんだはずです。 システム 1 には、さきほどの直線の長さのように間違っていたとしても『 見たまま 』を認識する機能と 2 つの文字から『 関連づけ 』をおこないストーリーを組み立てる機能があります。そのどちらもが自分の意識とは関係なく自動で、しかも強力に働いています。 システム 2 は、手動で論理的に動く 最初の二桁の掛け算を思い出してください。日本で算数を学んだ人であれば、二桁の掛け算のとき『考える』段階に移ると思います。これがシステム 2 のスイッチです。システム 1 は常時スイッチが入っていてほぼ自動で答えを出しますが、システム 2 は意識的に『考える』というステップを踏まないと動きません。システム 1 は自動ですが、システム 2 は手動です。 手動のため手間かかりますが、システム 1 にはない用心深さと慎重さがあります。こちらの問題をご覧ください。 『 バットとボールで 110 円、バットはボールより 100 円高い、ボールの値段は？ 』 即答で答えた人は 10 円と答える方が多いようです。こういう問題にはシステム 2 がうってつけで、論理的かつ正確に答えを出そうとします。答えは 5 円です。なかには頭の回転が早く即答できる人がいらっしゃることだと思います。そんな方にはこちらの問題を答えていだだきましょう。 3 日前から食べた夕飯の献立を口に出して発表しながら、『26x673』『245x287』『346x4546』の 3 問を 90 秒以内に解答してください。 いかがでしょうか？システム 2 は手動でうごき論理的で正確に答え出そうとしますが、複雑すぎる演算やマルチタスクにめっぽう弱くスタミナもありません。あきらめて電卓を叩いた方は、システム 2 がギブアップしたということかもしれません。 システム 1 と 2 の特徴は以下。どちらも良いところとそうでないところがあります。 デザインを再構築 これらシステム 1&2 の特性を踏まえた上で簡単なニュース記事のタイポグラフィを整理してみました。 発表資料の 58 ページからご覧ください。 speakerdeck.com こと細かく情報をシステム 1&2 のフィルターを通すことで、タイトルやリード、本文の行間、文字サイズ、それらがシステム 2 が情報を理解しやすくするための１つ機能として捉えることができます。当たり前に使っていたスキルや機能を別の視点で捉えることで違った深い意味を見出せるようになり、大きな発見につながりました。 今回はタイポグラフィだったのでシステム 2 寄りのものでしたが、ビジュアルアイデンティティが強く抽象的なデザインは、意図的にシステム 2 を封じ込めシステム 1 の直感性を利用して内容を理解してもらうこともできます。 システム 1&2 の 2 つの特性を踏まえて使いこなすことで、スキルの深い理解はもちろんですが、感覚とは違うデザインの伝え方の新しいヒントにもなりそうです。 さいごに YouTube や Instagram、LINE はどちらかというと直感性を促すシステム 1 が活躍するアプリです。それだけでなく身の回りにあるサービス全体がその傾向という印象をうけます。システム 1 は普段からスイッチが入っているため、比較的に簡易なステップで働きかけることができます。 一方でシステム 2 は複雑な演算には耐えれず、しっかりとケアしながらでないと十分な運用ができません。ただケアをしっかりすると恩恵も大きいといえます。 金融、教育、雇用、そして医療と、20 年前とは比較にならないほどインターネットは人生の節目に深く関わるようになったからです。人生に関わる選択をネットで行うとき、 直感だけでなくシステム 2 を働かせて熟考し納得のいく決断を行うことが、よりユーザーの利益につながる と私は考えています。 メドレーで提供しているサービスはユーザーの人生に少なからず関わる性質をもっています。すぐに結論づけしてもらうより、ユーザーにとって正しいと思える判断ができるように、 システム 2 をうまく働かせることができる環境をデザイナーとしてつくっていきたい と思います。 おまけ 今回のテックランチで参考にさせていただいた書籍は以下のものになります。 『 ファスト＆スロー（上・下） 』ダニエル・カーネマン 『 予想通りに不合理 』ダン・アリエリ 『 錯覚の科学 』クリストファー・チャブルス＆ダニエル・シモンズ 『 UI デザインの心理学 』ジェフ・ジョンソン 今回のお話は、本当に本当に表面の部分になります。流し読みでも参考になるので手に取って見てください。またこういうことに興味がわいたデザイナーさん・エンジニアさん、是非是非メドレーに遊びに来てください！（絶賛募集中です！） お知らせ メドレーでは、ジョブメドレーだけでなく、医師たちがつくるオンライン医療事典「 MEDLEY 」やオンライン診療アプリ「 CLINICS 」、口コミで探せる介護施設の検索サイト「 介護のほんね 」などのプロダクトも提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。 www.medley.jp 今後ともメドレーを、よろしくお願いいたします！

今回の内容について メドレー開発本部の 田中 です。 先日、Proxy 層を Elastic Beanstalk 上の Nginx で、App 層を EC2 インスタンスで構築する機会がありました。ここだけ見るととても普通に見えますが、制約があることで苦労した点もあり（ 前編参照 ）、制約を乗り越えるための工夫も含めてお話できる限り共有させていただきます。 前編では Proxy 層の構成として、主に Nginx を使用した Path Based Routing 周りについてのお話でした。後編では App 層で使用した EC2、 Systems Manager パラメータストアあたりについて共有いたします。 App 層の構成 App 層の方針や構築の流れ等をまとめると以下の通りです。 ゴールデンイメージとして OS 設定やサーバアプリケーションをインストールした image（AMI）を作成しておく 上記の AMI を元に、クライアント毎に EC2 インスタンスを作成する インスタンス作成時に必要な Tag の値や環境変数を設定しておく 環境変数はパラメータストアに登録 EC2 インスタンス起動時に、クライアントに応じた Tag や環境変数をもとにサーバアプリケーションのセットアップを行う 自身の内部 IP と Tag に設定したクライアント識別 ID を元に Route53 の PrivateDNS に登録する それでは、それぞれの詳細について説明していきたいと思います。 AMI 作成 Packer を使用して各インスタンス共通となる AMI を作成します。 provisioners で指定した構築用スクリプトで OS 設定や必要ライブラリ、またメインとなるサーバアプリケーションをインストールします。また、cloud-init を使用して初回起動時に動かすスクリプト類もコピーしておきます。 なお、cloud-init から実行するスクリプトは Git や S3 などから動的に取得する方法もありますが、さほどスクリプトの内容に変更は発生しない点と、内容的に変更ある場合は image 再作成がどちらにしても必要になりそうだったので割り切って image 内に含めることにしています。 作成した packer.json の provisioners 部分を抜粋するとこのような感じになります（説明コメント部分は実際には記載していません） "provisioners" : [ -- type: shell として、構築用スクリプト指定。ビルド時に実行される { "type" : "shell" , "scripts" : [ "scripts/provision.sh" ] }, -- type: file でインスタンス起動時に実行させるスクリプト群をコピー -- これらのスクリプトは cloud-init から実行される（cloud-init の設定は別途インスタンス作成時に行っている） { "type" : "file" , "source" : "./scripts" , "destination" : "/home/hoge" }, -- 上記のスクリプトに対して実行権限付与 { "type" : "shell" , "inline" : [ "chmod +x /home/hoge/scripts/*" ] } ] packer build でビルドした image が AWS に今回の共通で使用する AMI として登録されます EC2 インスタンス作成 作成した AMI を元に、クライアントごとのインスタンスを作成します。なお、インスタンス作成は Terraform や CloudFormation などは使わず、AWS CLI を利用したスクリプトを作成して実行しています。 インスタンス作成スクリプトはこのような流れの処理となります。 引数でクライアント識別 ID やその他サーバアプリケーションセットアップに必要となる環境変数を指定 AWS CLI で EC2 インスタンス作成 引数で指定された環境変数を AWS CLI でパラメータストアに登録 インスタンス作成 以下のように、 aws ec2 run-instances コマンドを使用し、Tag にクライアント識別 ID を指定して作成しています。 ここで指定したクライアント識別 ID を元にパラメータストアから自分用の環境変数を登録/取得したり、Private DNS 用のドメインに使用します。 aws ec2 run-instances \ --image-id ${ AMI_ID } \ --key-name ${ KEY_NAME } --region ${ REGION } \ --subnet-id ${ SUBNET_ID } \ --security-group-ids ${ SECURITY_GROUP } \ --user-data file:// ${ USER_DATA } \ --instance-type ${ INSTANCE_TYPE } \ --tag-specifications "ResourceType=instance,Tags=[{Key=ClientId,Value=${ CLIENT_ID }}]" \ --iam-instance-profile "Arn=${ SERVICE_ROLE }" user-data には初回起動時に実行したいスクリプト（Packer でビルド時にコピーしておいたスクリプト）を指定しているだけとなります。 #!/bin/bash /home/hoge/scripts/bootstrap.sh パラメータストアに環境変数登録 使用する環境変数は、Key は共通ですが値がクライアントによって異なります。そのため、HOGE という Key を使用する場合、 <クライアント識別 ID>.HOGE という形式でパラメータストアに登録しています。 （注. パラメータストアに 階層やタグ付けがサポートされた らしく、このあたりの構成は今後見直す予定です） 登録は aws ssm put-parameter を実行します aws ssm put-parameter \ --name ${ KEY } \ --value ${ VALUE } \ --type ${ PARAMETER_TYPE } \ # String、SecureString など --overwrite これでクライアントごとの EC2 インスタンスが作成、起動されます。次にインスタンス起動時の流れについてです。 EC2 インスタンス起動 起動時は、初回起動と毎回起動でそれぞれ以下のような処理を行います。 初回: パラメータストアから自身に関連する環境変数を取得し、サーバアプリケーションのセットアップ 毎回: 自身の内部 IP を Route53 の Private DNS に登録/更新 内部 IP は固定しておらず起動時に割り振られるため、毎回更新するようにしています。 それではそれぞれの内容について見ていきます。 パラメータストアから環境変数取得 登録時の内容で記載しましたが、環境変数は <クライアント識別 ID>.HOGE という形式で登録しています。そのため、まずは自身のクライアント識別 ID を判定した後に必要な環境変数を aws ssm get-parameters で取得します。 # 自身のインスタンス ID をメタデータから取得 INSTANCE_ID =$( curl -s https://169.254.169.254/latest/meta-data/instance-id ) # クライアント識別 ID をインスタンス作成時に指定した Tag から取得 # (describe-instances の filter に自身のインスタンス ID を指定) CLIENT_ID_TAG =$( aws ec2 describe-instances \ --region=${ REGION } \ --filters "Name=instance-id,Values=${ INSTANCE_ID }" \ | jq -r '.Reservations[].Instances[].Tags[] | select(.Key == "ClientId").Value' ) # 環境変数を取得 # タイプを SecureString にしている変数もあるため、一律 --with-decryption オプションを指定している HOGE =$( aws ssm get-parameters \ --name "${ CLIENT_ID_TAG }.HOGE" \ --with-decryption --region ${ REGION } \ | jq -r ".Parameters[].Value" ) export HOGE =${ HOGE } 内部 IP を Private DNS に登録 最後に、Proxy 層から Private DNS で名前解決できるように自身の IP を Route 53 に登録してやります。 なお、Route53 には事前に対象の Hosted Zone を Private Hosted Zone for Amazon VPC タイプとして登録しておきます。ここでは例として Domain Name を local とします。 EC2 インスタンスから登録される RecordSet は以下の形式とします。 Name: <クライアント識別 ID>.local Type: CNAME Value: EC2 インスタンスの内部 IP これらを行うスクリプト例は以下となります。 # 内部 IP を取得 # (describe-instances の filter に自身のインスタンス ID を指定) PRIVATE_IP =$( aws ec2 describe-instances \ --region=${ REGION } \ --filters "Name=instance-id,Values=${ INSTANCE_ID }" \ | jq -r '.Reservations[].Instances[].PrivateIpAddress' ) # Route53 の登録先 Hosted Zone ID を取得 # SEARCH_KEY は今回の例でいうと 'local.' になります HOSTED_ZONE_ID =$( aws route53 list-hosted-zones \ --region=${ REGION } \ | jq -r ".HostedZones[] | select(.Name == \" ${ SEARCH_KEY } \" ).Id" ) # この後の登録コマンドで指定するための定義ファイル # 毎起動時の登録用（IP が変わるため）に、Action には 'UPSERT' を指定 RECORDSET_FILE = "/tmp/create_recordset.json" cat << EOT > ${ RECORDSET_FILE } { "Changes": [ { "Action": "UPSERT", "ResourceRecordSet": { "Name": "<クライアント識別 ID>.local", "Type": "CNAME", "TTL": 300, "ResourceRecords": [ { "Value": "${ PRIVATE_IP }" } ] } } ] } EOT # 作成した定義ファイルを指定し、Route53 に登録 aws route53 change-resource-record-sets \ --hosted-zone-id ${ HOSTED_ZONE_ID } \ --change-batch file:/// ${ RECORDSET_FILE } 実行するステップはやや多いですが、このような構成をとることで VPC 内ではドメイン指定でのアクセスが可能となるため、IP を意識する必要がなくなるため柔軟な構成になるかと思います。 今回のまとめ いまさらインスタンス立てるとかめんどくさいなぁ、、、とか思いながら色々調べて構築しましたが、EC2 まわりのサービスも増えてるんだなぁ、なんて感じました（特にパラメータストアはとても便利） パラメータストア以外にも Systems Manager には Run Command や Patch Manager など EC2 インスタンスを管理する上でとても便利な仕組みが揃っていますのでこのあたりも導入していきたいと思います。 余談ですが、Systems Manager の存在は re:Invent 2016 で発表された時から名前だけは知ってましたが、今回の対応するまでずっとオンプレ専用のサービスだと勘違いしてて記憶から消えかけていました。。。 最後に 前編を Proxy 層 （Nginx）、後編を App 層（EC2）について書かせていただきましたがいかかだったでしょうか。 そもそもの要件自体がけっこう特殊だったりもするので、なんでこんな構成に？みたいなとこもあるかも知れませんが、どなたかの参考になれば幸いです。もう少し聞いてみたい、というかたは wantedly の「 話を聞いてみたい 」ボタンからどうぞ。 ※前編をあらためて読みたい方はこちらからどうぞ https://developer.medley.jp/entry/2017/08/24/120000_01 お知らせ メドレーでは、医師たちがつくるオンライン医療事典「 MEDLEY 」、オンライン診療アプリ「 CLINICS 」、医療介護の求人サイト「 ジョブメドレー 」、口コミで探せる介護施設の検索サイト「 介護のほんね 」などのプロダクトを提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。 メドレーで一緒に医療体験を変えるプロダクト作りに関わりたい方のご連絡お待ちしております。 メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp

今回の内容について メドレー開発本部の 田中 です。 先日、Proxy 層を Elastic Beanstalk 上の Nginx で、App 層を EC2 インスタンスで構築する機会がありました。ここだけ見るととても普通に見えますが、制約があることで苦労した点もあり（ 前編参照 ）、制約を乗り越えるための工夫も含めてお話できる限り共有させていただきます。 前編では Proxy 層の構成として、主に Nginx を使用した Path Based Routing 周りについてのお話でした。後編では App 層で使用した EC2、 Systems Manager パラメータストアあたりについて共有いたします。 App 層の構成 App 層の方針や構築の流れ等をまとめると以下の通りです。 ゴールデンイメージとして OS 設定やサーバアプリケーションをインストールした image（AMI）を作成しておく 上記の AMI を元に、クライアント毎に EC2 インスタンスを作成する インスタンス作成時に必要な Tag の値や環境変数を設定しておく 環境変数はパラメータストアに登録 EC2 インスタンス起動時に、クライアントに応じた Tag や環境変数をもとにサーバアプリケーションのセットアップを行う 自身の内部 IP と Tag に設定したクライアント識別 ID を元に Route53 の PrivateDNS に登録する それでは、それぞれの詳細について説明していきたいと思います。 AMI 作成 Packer を使用して各インスタンス共通となる AMI を作成します。 provisioners で指定した構築用スクリプトで OS 設定や必要ライブラリ、またメインとなるサーバアプリケーションをインストールします。また、cloud-init を使用して初回起動時に動かすスクリプト類もコピーしておきます。 なお、cloud-init から実行するスクリプトは Git や S3 などから動的に取得する方法もありますが、さほどスクリプトの内容に変更は発生しない点と、内容的に変更ある場合は image 再作成がどちらにしても必要になりそうだったので割り切って image 内に含めることにしています。 作成した packer.json の provisioners 部分を抜粋するとこのような感じになります（説明コメント部分は実際には記載していません） "provisioners" : [ -- type: shell として、構築用スクリプト指定。ビルド時に実行される { "type" : "shell" , "scripts" : [ "scripts/provision.sh" ] }, -- type: file でインスタンス起動時に実行させるスクリプト群をコピー -- これらのスクリプトは cloud-init から実行される（cloud-init の設定は別途インスタンス作成時に行っている） { "type" : "file" , "source" : "./scripts" , "destination" : "/home/hoge" }, -- 上記のスクリプトに対して実行権限付与 { "type" : "shell" , "inline" : [ "chmod +x /home/hoge/scripts/*" ] } ] packer build でビルドした image が AWS に今回の共通で使用する AMI として登録されます EC2 インスタンス作成 作成した AMI を元に、クライアントごとのインスタンスを作成します。なお、インスタンス作成は Terraform や CloudFormation などは使わず、AWS CLI を利用したスクリプトを作成して実行しています。 インスタンス作成スクリプトはこのような流れの処理となります。 引数でクライアント識別 ID やその他サーバアプリケーションセットアップに必要となる環境変数を指定 AWS CLI で EC2 インスタンス作成 引数で指定された環境変数を AWS CLI でパラメータストアに登録 インスタンス作成 以下のように、 aws ec2 run-instances コマンドを使用し、Tag にクライアント識別 ID を指定して作成しています。 ここで指定したクライアント識別 ID を元にパラメータストアから自分用の環境変数を登録/取得したり、Private DNS 用のドメインに使用します。 aws ec2 run-instances \ --image-id ${ AMI_ID } \ --key-name ${ KEY_NAME } --region ${ REGION } \ --subnet-id ${ SUBNET_ID } \ --security-group-ids ${ SECURITY_GROUP } \ --user-data file:// ${ USER_DATA } \ --instance-type ${ INSTANCE_TYPE } \ --tag-specifications "ResourceType=instance,Tags=[{Key=ClientId,Value=${ CLIENT_ID }}]" \ --iam-instance-profile "Arn=${ SERVICE_ROLE }" user-data には初回起動時に実行したいスクリプト（Packer でビルド時にコピーしておいたスクリプト）を指定しているだけとなります。 #!/bin/bash /home/hoge/scripts/bootstrap.sh パラメータストアに環境変数登録 使用する環境変数は、Key は共通ですが値がクライアントによって異なります。そのため、HOGE という Key を使用する場合、 <クライアント識別 ID>.HOGE という形式でパラメータストアに登録しています。 （注. パラメータストアに 階層やタグ付けがサポートされた らしく、このあたりの構成は今後見直す予定です） 登録は aws ssm put-parameter を実行します aws ssm put-parameter \ --name ${ KEY } \ --value ${ VALUE } \ --type ${ PARAMETER_TYPE } \ # String、SecureString など --overwrite これでクライアントごとの EC2 インスタンスが作成、起動されます。次にインスタンス起動時の流れについてです。 EC2 インスタンス起動 起動時は、初回起動と毎回起動でそれぞれ以下のような処理を行います。 初回: パラメータストアから自身に関連する環境変数を取得し、サーバアプリケーションのセットアップ 毎回: 自身の内部 IP を Route53 の Private DNS に登録/更新 内部 IP は固定しておらず起動時に割り振られるため、毎回更新するようにしています。 それではそれぞれの内容について見ていきます。 パラメータストアから環境変数取得 登録時の内容で記載しましたが、環境変数は <クライアント識別 ID>.HOGE という形式で登録しています。そのため、まずは自身のクライアント識別 ID を判定した後に必要な環境変数を aws ssm get-parameters で取得します。 # 自身のインスタンス ID をメタデータから取得 INSTANCE_ID =$( curl -s https://169.254.169.254/latest/meta-data/instance-id ) # クライアント識別 ID をインスタンス作成時に指定した Tag から取得 # (describe-instances の filter に自身のインスタンス ID を指定) CLIENT_ID_TAG =$( aws ec2 describe-instances \ --region=${ REGION } \ --filters "Name=instance-id,Values=${ INSTANCE_ID }" \ | jq -r '.Reservations[].Instances[].Tags[] | select(.Key == "ClientId").Value' ) # 環境変数を取得 # タイプを SecureString にしている変数もあるため、一律 --with-decryption オプションを指定している HOGE =$( aws ssm get-parameters \ --name "${ CLIENT_ID_TAG }.HOGE" \ --with-decryption --region ${ REGION } \ | jq -r ".Parameters[].Value" ) export HOGE =${ HOGE } 内部 IP を Private DNS に登録 最後に、Proxy 層から Private DNS で名前解決できるように自身の IP を Route 53 に登録してやります。 なお、Route53 には事前に対象の Hosted Zone を Private Hosted Zone for Amazon VPC タイプとして登録しておきます。ここでは例として Domain Name を local とします。 EC2 インスタンスから登録される RecordSet は以下の形式とします。 Name: <クライアント識別 ID>.local Type: CNAME Value: EC2 インスタンスの内部 IP これらを行うスクリプト例は以下となります。 # 内部 IP を取得 # (describe-instances の filter に自身のインスタンス ID を指定) PRIVATE_IP =$( aws ec2 describe-instances \ --region=${ REGION } \ --filters "Name=instance-id,Values=${ INSTANCE_ID }" \ | jq -r '.Reservations[].Instances[].PrivateIpAddress' ) # Route53 の登録先 Hosted Zone ID を取得 # SEARCH_KEY は今回の例でいうと 'local.' になります HOSTED_ZONE_ID =$( aws route53 list-hosted-zones \ --region=${ REGION } \ | jq -r ".HostedZones[] | select(.Name == \" ${ SEARCH_KEY } \" ).Id" ) # この後の登録コマンドで指定するための定義ファイル # 毎起動時の登録用（IP が変わるため）に、Action には 'UPSERT' を指定 RECORDSET_FILE = "/tmp/create_recordset.json" cat << EOT > ${ RECORDSET_FILE } { "Changes": [ { "Action": "UPSERT", "ResourceRecordSet": { "Name": "<クライアント識別 ID>.local", "Type": "CNAME", "TTL": 300, "ResourceRecords": [ { "Value": "${ PRIVATE_IP }" } ] } } ] } EOT # 作成した定義ファイルを指定し、Route53 に登録 aws route53 change-resource-record-sets \ --hosted-zone-id ${ HOSTED_ZONE_ID } \ --change-batch file:/// ${ RECORDSET_FILE } 実行するステップはやや多いですが、このような構成をとることで VPC 内ではドメイン指定でのアクセスが可能となるため、IP を意識する必要がなくなるため柔軟な構成になるかと思います。 今回のまとめ いまさらインスタンス立てるとかめんどくさいなぁ、、、とか思いながら色々調べて構築しましたが、EC2 まわりのサービスも増えてるんだなぁ、なんて感じました（特にパラメータストアはとても便利） パラメータストア以外にも Systems Manager には Run Command や Patch Manager など EC2 インスタンスを管理する上でとても便利な仕組みが揃っていますのでこのあたりも導入していきたいと思います。 余談ですが、Systems Manager の存在は re:Invent 2016 で発表された時から名前だけは知ってましたが、今回の対応するまでずっとオンプレ専用のサービスだと勘違いしてて記憶から消えかけていました。。。 最後に 前編を Proxy 層 （Nginx）、後編を App 層（EC2）について書かせていただきましたがいかかだったでしょうか。 そもそもの要件自体がけっこう特殊だったりもするので、なんでこんな構成に？みたいなとこもあるかも知れませんが、どなたかの参考になれば幸いです。もう少し聞いてみたい、というかたは wantedly の「 話を聞いてみたい 」ボタンからどうぞ。 ※前編をあらためて読みたい方はこちらからどうぞ https://developer.medley.jp/entry/2017/08/24/120000_01 お知らせ メドレーでは、医師たちがつくるオンライン医療事典「 MEDLEY 」、オンライン診療アプリ「 CLINICS 」、医療介護の求人サイト「 ジョブメドレー 」、口コミで探せる介護施設の検索サイト「 介護のほんね 」などのプロダクトを提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。 メドレーで一緒に医療体験を変えるプロダクト作りに関わりたい方のご連絡お待ちしております。 https://www.medley.jp/recruit/creative.html

今回の内容について メドレー開発本部の 田中 です。 先日、Proxy 層を Elastic Beanstalk 上の Nginx で、App 層を EC2 インスタンスで構築する機会がありました。ここだけ見るととても普通に見えますが、制約があることで苦労した点もあり（ 前編参照 ）、制約を乗り越えるための工夫も含めてお話できる限り共有させていただきます。 前編では Proxy 層の構成として、主に Nginx を使用した Path Based Routing 周りについてのお話でした。後編では App 層で使用した EC2、 Systems Manager パラメータストアあたりについて共有いたします。 App 層の構成 App 層の方針や構築の流れ等をまとめると以下の通りです。 ゴールデンイメージとして OS 設定やサーバアプリケーションをインストールした image（AMI）を作成しておく 上記の AMI を元に、クライアント毎に EC2 インスタンスを作成する インスタンス作成時に必要な Tag の値や環境変数を設定しておく 環境変数はパラメータストアに登録 EC2 インスタンス起動時に、クライアントに応じた Tag や環境変数をもとにサーバアプリケーションのセットアップを行う 自身の内部 IP と Tag に設定したクライアント識別 ID を元に Route53 の PrivateDNS に登録する それでは、それぞれの詳細について説明していきたいと思います。 AMI 作成 Packer を使用して各インスタンス共通となる AMI を作成します。 provisioners で指定した構築用スクリプトで OS 設定や必要ライブラリ、またメインとなるサーバアプリケーションをインストールします。また、cloud-init を使用して初回起動時に動かすスクリプト類もコピーしておきます。 なお、cloud-init から実行するスクリプトは Git や S3 などから動的に取得する方法もありますが、さほどスクリプトの内容に変更は発生しない点と、内容的に変更ある場合は image 再作成がどちらにしても必要になりそうだったので割り切って image 内に含めることにしています。 作成した packer.json の provisioners 部分を抜粋するとこのような感じになります（説明コメント部分は実際には記載していません） "provisioners" : [ -- type: shell として、構築用スクリプト指定。ビルド時に実行される { "type" : "shell" , "scripts" : [ "scripts/provision.sh" ] }, -- type: file でインスタンス起動時に実行させるスクリプト群をコピー -- これらのスクリプトは cloud-init から実行される（cloud-init の設定は別途インスタンス作成時に行っている） { "type" : "file" , "source" : "./scripts" , "destination" : "/home/hoge" }, -- 上記のスクリプトに対して実行権限付与 { "type" : "shell" , "inline" : [ "chmod +x /home/hoge/scripts/*" ] } ] packer build でビルドした image が AWS に今回の共通で使用する AMI として登録されます EC2 インスタンス作成 作成した AMI を元に、クライアントごとのインスタンスを作成します。なお、インスタンス作成は Terraform や CloudFormation などは使わず、AWS CLI を利用したスクリプトを作成して実行しています。 インスタンス作成スクリプトはこのような流れの処理となります。 引数でクライアント識別 ID やその他サーバアプリケーションセットアップに必要となる環境変数を指定 AWS CLI で EC2 インスタンス作成 引数で指定された環境変数を AWS CLI でパラメータストアに登録 インスタンス作成 以下のように、 aws ec2 run-instances コマンドを使用し、Tag にクライアント識別 ID を指定して作成しています。 ここで指定したクライアント識別 ID を元にパラメータストアから自分用の環境変数を登録/取得したり、Private DNS 用のドメインに使用します。 aws ec2 run-instances \ --image-id ${ AMI_ID } \ --key-name ${ KEY_NAME } --region ${ REGION } \ --subnet-id ${ SUBNET_ID } \ --security-group-ids ${ SECURITY_GROUP } \ --user-data file:// ${ USER_DATA } \ --instance-type ${ INSTANCE_TYPE } \ --tag-specifications "ResourceType=instance,Tags=[{Key=ClientId,Value=${ CLIENT_ID }}]" \ --iam-instance-profile "Arn=${ SERVICE_ROLE }" user-data には初回起動時に実行したいスクリプト（Packer でビルド時にコピーしておいたスクリプト）を指定しているだけとなります。 #!/bin/bash /home/hoge/scripts/bootstrap.sh パラメータストアに環境変数登録 使用する環境変数は、Key は共通ですが値がクライアントによって異なります。そのため、HOGE という Key を使用する場合、 <クライアント識別 ID>.HOGE という形式でパラメータストアに登録しています。 （注. パラメータストアに 階層やタグ付けがサポートされた らしく、このあたりの構成は今後見直す予定です） 登録は aws ssm put-parameter を実行します aws ssm put-parameter \ --name ${ KEY } \ --value ${ VALUE } \ --type ${ PARAMETER_TYPE } \ # String、SecureString など --overwrite これでクライアントごとの EC2 インスタンスが作成、起動されます。次にインスタンス起動時の流れについてです。 EC2 インスタンス起動 起動時は、初回起動と毎回起動でそれぞれ以下のような処理を行います。 初回: パラメータストアから自身に関連する環境変数を取得し、サーバアプリケーションのセットアップ 毎回: 自身の内部 IP を Route53 の Private DNS に登録/更新 内部 IP は固定しておらず起動時に割り振られるため、毎回更新するようにしています。 それではそれぞれの内容について見ていきます。 パラメータストアから環境変数取得 登録時の内容で記載しましたが、環境変数は <クライアント識別 ID>.HOGE という形式で登録しています。そのため、まずは自身のクライアント識別 ID を判定した後に必要な環境変数を aws ssm get-parameters で取得します。 # 自身のインスタンス ID をメタデータから取得 INSTANCE_ID =$( curl -s https://169.254.169.254/latest/meta-data/instance-id ) # クライアント識別 ID をインスタンス作成時に指定した Tag から取得 # (describe-instances の filter に自身のインスタンス ID を指定) CLIENT_ID_TAG =$( aws ec2 describe-instances \ --region=${ REGION } \ --filters "Name=instance-id,Values=${ INSTANCE_ID }" \ | jq -r '.Reservations[].Instances[].Tags[] | select(.Key == "ClientId").Value' ) # 環境変数を取得 # タイプを SecureString にしている変数もあるため、一律 --with-decryption オプションを指定している HOGE =$( aws ssm get-parameters \ --name "${ CLIENT_ID_TAG }.HOGE" \ --with-decryption --region ${ REGION } \ | jq -r ".Parameters[].Value" ) export HOGE =${ HOGE } 内部 IP を Private DNS に登録 最後に、Proxy 層から Private DNS で名前解決できるように自身の IP を Route 53 に登録してやります。 なお、Route53 には事前に対象の Hosted Zone を Private Hosted Zone for Amazon VPC タイプとして登録しておきます。ここでは例として Domain Name を local とします。 EC2 インスタンスから登録される RecordSet は以下の形式とします。 Name: <クライアント識別 ID>.local Type: CNAME Value: EC2 インスタンスの内部 IP これらを行うスクリプト例は以下となります。 # 内部 IP を取得 # (describe-instances の filter に自身のインスタンス ID を指定) PRIVATE_IP =$( aws ec2 describe-instances \ --region=${ REGION } \ --filters "Name=instance-id,Values=${ INSTANCE_ID }" \ | jq -r '.Reservations[].Instances[].PrivateIpAddress' ) # Route53 の登録先 Hosted Zone ID を取得 # SEARCH_KEY は今回の例でいうと 'local.' になります HOSTED_ZONE_ID =$( aws route53 list-hosted-zones \ --region=${ REGION } \ | jq -r ".HostedZones[] | select(.Name == \" ${ SEARCH_KEY } \" ).Id" ) # この後の登録コマンドで指定するための定義ファイル # 毎起動時の登録用（IP が変わるため）に、Action には 'UPSERT' を指定 RECORDSET_FILE = "/tmp/create_recordset.json" cat << EOT > ${ RECORDSET_FILE } { "Changes": [ { "Action": "UPSERT", "ResourceRecordSet": { "Name": "<クライアント識別 ID>.local", "Type": "CNAME", "TTL": 300, "ResourceRecords": [ { "Value": "${ PRIVATE_IP }" } ] } } ] } EOT # 作成した定義ファイルを指定し、Route53 に登録 aws route53 change-resource-record-sets \ --hosted-zone-id ${ HOSTED_ZONE_ID } \ --change-batch file:/// ${ RECORDSET_FILE } 実行するステップはやや多いですが、このような構成をとることで VPC 内ではドメイン指定でのアクセスが可能となるため、IP を意識する必要がなくなるため柔軟な構成になるかと思います。 今回のまとめ いまさらインスタンス立てるとかめんどくさいなぁ、、、とか思いながら色々調べて構築しましたが、EC2 まわりのサービスも増えてるんだなぁ、なんて感じました（特にパラメータストアはとても便利） パラメータストア以外にも Systems Manager には Run Command や Patch Manager など EC2 インスタンスを管理する上でとても便利な仕組みが揃っていますのでこのあたりも導入していきたいと思います。 余談ですが、Systems Manager の存在は re:Invent 2016 で発表された時から名前だけは知ってましたが、今回の対応するまでずっとオンプレ専用のサービスだと勘違いしてて記憶から消えかけていました。。。 最後に 前編を Proxy 層 （Nginx）、後編を App 層（EC2）について書かせていただきましたがいかかだったでしょうか。 そもそもの要件自体がけっこう特殊だったりもするので、なんでこんな構成に？みたいなとこもあるかも知れませんが、どなたかの参考になれば幸いです。もう少し聞いてみたい、というかたは wantedly の「 話を聞いてみたい 」ボタンからどうぞ。 ※前編をあらためて読みたい方はこちらからどうぞ https://developer.medley.jp/entry/2017/08/24/120000_01 お知らせ メドレーでは、医師たちがつくるオンライン医療事典「 MEDLEY 」、オンライン診療アプリ「 CLINICS 」、医療介護の求人サイト「 ジョブメドレー 」、口コミで探せる介護施設の検索サイト「 介護のほんね 」などのプロダクトを提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。 メドレーで一緒に医療体験を変えるプロダクト作りに関わりたい方のご連絡お待ちしております。 メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp

今回の内容について メドレー開発本部の 田中 です。 先日、Proxy 層を Elastic Beanstalk 上の Nginx で、App 層を EC2 インスタンスで構築する機会がありました。ここだけ見るととても普通に見えますが、制約があることで苦労した点もあり（ 前編参照 ）、制約を乗り越えるための工夫も含めてお話できる限り共有させていただきます。 前編では Proxy 層の構成として、主に Nginx を使用した Path Based Routing 周りについてのお話でした。後編では App 層で使用した EC2、 Systems Manager パラメータストアあたりについて共有いたします。 App 層の構成 App 層の方針や構築の流れ等をまとめると以下の通りです。 ゴールデンイメージとして OS 設定やサーバアプリケーションをインストールした image（AMI）を作成しておく 上記の AMI を元に、クライアント毎に EC2 インスタンスを作成する インスタンス作成時に必要な Tag の値や環境変数を設定しておく 環境変数はパラメータストアに登録 EC2 インスタンス起動時に、クライアントに応じた Tag や環境変数をもとにサーバアプリケーションのセットアップを行う 自身の内部 IP と Tag に設定したクライアント識別 ID を元に Route53 の PrivateDNS に登録する それでは、それぞれの詳細について説明していきたいと思います。 AMI 作成 Packer を使用して各インスタンス共通となる AMI を作成します。 provisioners で指定した構築用スクリプトで OS 設定や必要ライブラリ、またメインとなるサーバアプリケーションをインストールします。また、cloud-init を使用して初回起動時に動かすスクリプト類もコピーしておきます。 なお、cloud-init から実行するスクリプトは Git や S3 などから動的に取得する方法もありますが、さほどスクリプトの内容に変更は発生しない点と、内容的に変更ある場合は image 再作成がどちらにしても必要になりそうだったので割り切って image 内に含めることにしています。 作成した packer.json の provisioners 部分を抜粋するとこのような感じになります（説明コメント部分は実際には記載していません） "provisioners" : [ -- type: shell として、構築用スクリプト指定。ビルド時に実行される { "type" : "shell" , "scripts" : [ "scripts/provision.sh" ] }, -- type: file でインスタンス起動時に実行させるスクリプト群をコピー -- これらのスクリプトは cloud-init から実行される（cloud-init の設定は別途インスタンス作成時に行っている） { "type" : "file" , "source" : "./scripts" , "destination" : "/home/hoge" }, -- 上記のスクリプトに対して実行権限付与 { "type" : "shell" , "inline" : [ "chmod +x /home/hoge/scripts/*" ] } ] packer build でビルドした image が AWS に今回の共通で使用する AMI として登録されます EC2 インスタンス作成 作成した AMI を元に、クライアントごとのインスタンスを作成します。なお、インスタンス作成は Terraform や CloudFormation などは使わず、AWS CLI を利用したスクリプトを作成して実行しています。 インスタンス作成スクリプトはこのような流れの処理となります。 引数でクライアント識別 ID やその他サーバアプリケーションセットアップに必要となる環境変数を指定 AWS CLI で EC2 インスタンス作成 引数で指定された環境変数を AWS CLI でパラメータストアに登録 インスタンス作成 以下のように、 aws ec2 run-instances コマンドを使用し、Tag にクライアント識別 ID を指定して作成しています。 ここで指定したクライアント識別 ID を元にパラメータストアから自分用の環境変数を登録/取得したり、Private DNS 用のドメインに使用します。 aws ec2 run-instances \ --image-id ${ AMI_ID } \ --key-name ${ KEY_NAME } --region ${ REGION } \ --subnet-id ${ SUBNET_ID } \ --security-group-ids ${ SECURITY_GROUP } \ --user-data file:// ${ USER_DATA } \ --instance-type ${ INSTANCE_TYPE } \ --tag-specifications "ResourceType=instance,Tags=[{Key=ClientId,Value=${ CLIENT_ID }}]" \ --iam-instance-profile "Arn=${ SERVICE_ROLE }" user-data には初回起動時に実行したいスクリプト（Packer でビルド時にコピーしておいたスクリプト）を指定しているだけとなります。 #!/bin/bash /home/hoge/scripts/bootstrap.sh パラメータストアに環境変数登録 使用する環境変数は、Key は共通ですが値がクライアントによって異なります。そのため、HOGE という Key を使用する場合、 <クライアント識別 ID>.HOGE という形式でパラメータストアに登録しています。 （注. パラメータストアに 階層やタグ付けがサポートされた らしく、このあたりの構成は今後見直す予定です） 登録は aws ssm put-parameter を実行します aws ssm put-parameter \ --name ${ KEY } \ --value ${ VALUE } \ --type ${ PARAMETER_TYPE } \ # String、SecureString など --overwrite これでクライアントごとの EC2 インスタンスが作成、起動されます。次にインスタンス起動時の流れについてです。 EC2 インスタンス起動 起動時は、初回起動と毎回起動でそれぞれ以下のような処理を行います。 初回: パラメータストアから自身に関連する環境変数を取得し、サーバアプリケーションのセットアップ 毎回: 自身の内部 IP を Route53 の Private DNS に登録/更新 内部 IP は固定しておらず起動時に割り振られるため、毎回更新するようにしています。 それではそれぞれの内容について見ていきます。 パラメータストアから環境変数取得 登録時の内容で記載しましたが、環境変数は <クライアント識別 ID>.HOGE という形式で登録しています。そのため、まずは自身のクライアント識別 ID を判定した後に必要な環境変数を aws ssm get-parameters で取得します。 # 自身のインスタンス ID をメタデータから取得 INSTANCE_ID =$( curl -s https://169.254.169.254/latest/meta-data/instance-id ) # クライアント識別 ID をインスタンス作成時に指定した Tag から取得 # (describe-instances の filter に自身のインスタンス ID を指定) CLIENT_ID_TAG =$( aws ec2 describe-instances \ --region=${ REGION } \ --filters "Name=instance-id,Values=${ INSTANCE_ID }" \ | jq -r '.Reservations[].Instances[].Tags[] | select(.Key == "ClientId").Value' ) # 環境変数を取得 # タイプを SecureString にしている変数もあるため、一律 --with-decryption オプションを指定している HOGE =$( aws ssm get-parameters \ --name "${ CLIENT_ID_TAG }.HOGE" \ --with-decryption --region ${ REGION } \ | jq -r ".Parameters[].Value" ) export HOGE =${ HOGE } 内部 IP を Private DNS に登録 最後に、Proxy 層から Private DNS で名前解決できるように自身の IP を Route 53 に登録してやります。 なお、Route53 には事前に対象の Hosted Zone を Private Hosted Zone for Amazon VPC タイプとして登録しておきます。ここでは例として Domain Name を local とします。 EC2 インスタンスから登録される RecordSet は以下の形式とします。 Name: <クライアント識別 ID>.local Type: CNAME Value: EC2 インスタンスの内部 IP これらを行うスクリプト例は以下となります。 # 内部 IP を取得 # (describe-instances の filter に自身のインスタンス ID を指定) PRIVATE_IP =$( aws ec2 describe-instances \ --region=${ REGION } \ --filters "Name=instance-id,Values=${ INSTANCE_ID }" \ | jq -r '.Reservations[].Instances[].PrivateIpAddress' ) # Route53 の登録先 Hosted Zone ID を取得 # SEARCH_KEY は今回の例でいうと 'local.' になります HOSTED_ZONE_ID =$( aws route53 list-hosted-zones \ --region=${ REGION } \ | jq -r ".HostedZones[] | select(.Name == \" ${ SEARCH_KEY } \" ).Id" ) # この後の登録コマンドで指定するための定義ファイル # 毎起動時の登録用（IP が変わるため）に、Action には 'UPSERT' を指定 RECORDSET_FILE = "/tmp/create_recordset.json" cat << EOT > ${ RECORDSET_FILE } { "Changes": [ { "Action": "UPSERT", "ResourceRecordSet": { "Name": "<クライアント識別 ID>.local", "Type": "CNAME", "TTL": 300, "ResourceRecords": [ { "Value": "${ PRIVATE_IP }" } ] } } ] } EOT # 作成した定義ファイルを指定し、Route53 に登録 aws route53 change-resource-record-sets \ --hosted-zone-id ${ HOSTED_ZONE_ID } \ --change-batch file:/// ${ RECORDSET_FILE } 実行するステップはやや多いですが、このような構成をとることで VPC 内ではドメイン指定でのアクセスが可能となるため、IP を意識する必要がなくなるため柔軟な構成になるかと思います。 今回のまとめ いまさらインスタンス立てるとかめんどくさいなぁ、、、とか思いながら色々調べて構築しましたが、EC2 まわりのサービスも増えてるんだなぁ、なんて感じました（特にパラメータストアはとても便利） パラメータストア以外にも Systems Manager には Run Command や Patch Manager など EC2 インスタンスを管理する上でとても便利な仕組みが揃っていますのでこのあたりも導入していきたいと思います。 余談ですが、Systems Manager の存在は re:Invent 2016 で発表された時から名前だけは知ってましたが、今回の対応するまでずっとオンプレ専用のサービスだと勘違いしてて記憶から消えかけていました。。。 最後に 前編を Proxy 層 （Nginx）、後編を App 層（EC2）について書かせていただきましたがいかかだったでしょうか。 そもそもの要件自体がけっこう特殊だったりもするので、なんでこんな構成に？みたいなとこもあるかも知れませんが、どなたかの参考になれば幸いです。もう少し聞いてみたい、というかたは wantedly の「 話を聞いてみたい 」ボタンからどうぞ。 ※前編をあらためて読みたい方はこちらからどうぞ https://developer.medley.jp/entry/2017/08/24/120000_01 お知らせ メドレーでは、医師たちがつくるオンライン医療事典「 MEDLEY 」、オンライン診療アプリ「 CLINICS 」、医療介護の求人サイト「 ジョブメドレー 」、口コミで探せる介護施設の検索サイト「 介護のほんね 」などのプロダクトを提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。 メドレーで一緒に医療体験を変えるプロダクト作りに関わりたい方のご連絡お待ちしております。 メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp

今回の内容について メドレー開発本部の 田中 です。 先日、Proxy 層を Elastic Beanstalk 上の Nginx で、App 層を EC2 インスタンスで構築する機会がありました。ここだけ見るととても普通に見えますが、制約があることで苦労した点もあり（ 前編参照 ）、制約を乗り越えるための工夫も含めてお話できる限り共有させていただきます。 前編では Proxy 層の構成として、主に Nginx を使用した Path Based Routing 周りについてのお話でした。後編では App 層で使用した EC2、 Systems Manager パラメータストアあたりについて共有いたします。 App 層の構成 App 層の方針や構築の流れ等をまとめると以下の通りです。 ゴールデンイメージとして OS 設定やサーバアプリケーションをインストールした image（AMI）を作成しておく 上記の AMI を元に、クライアント毎に EC2 インスタンスを作成する インスタンス作成時に必要な Tag の値や環境変数を設定しておく 環境変数はパラメータストアに登録 EC2 インスタンス起動時に、クライアントに応じた Tag や環境変数をもとにサーバアプリケーションのセットアップを行う 自身の内部 IP と Tag に設定したクライアント識別 ID を元に Route53 の PrivateDNS に登録する それでは、それぞれの詳細について説明していきたいと思います。 AMI 作成 Packer を使用して各インスタンス共通となる AMI を作成します。 provisioners で指定した構築用スクリプトで OS 設定や必要ライブラリ、またメインとなるサーバアプリケーションをインストールします。また、cloud-init を使用して初回起動時に動かすスクリプト類もコピーしておきます。 なお、cloud-init から実行するスクリプトは Git や S3 などから動的に取得する方法もありますが、さほどスクリプトの内容に変更は発生しない点と、内容的に変更ある場合は image 再作成がどちらにしても必要になりそうだったので割り切って image 内に含めることにしています。 作成した packer.json の provisioners 部分を抜粋するとこのような感じになります（説明コメント部分は実際には記載していません） "provisioners" : [ -- type: shell として、構築用スクリプト指定。ビルド時に実行される { "type" : "shell" , "scripts" : [ "scripts/provision.sh" ] }, -- type: file でインスタンス起動時に実行させるスクリプト群をコピー -- これらのスクリプトは cloud-init から実行される（cloud-init の設定は別途インスタンス作成時に行っている） { "type" : "file" , "source" : "./scripts" , "destination" : "/home/hoge" }, -- 上記のスクリプトに対して実行権限付与 { "type" : "shell" , "inline" : [ "chmod +x /home/hoge/scripts/*" ] } ] packer build でビルドした image が AWS に今回の共通で使用する AMI として登録されます EC2 インスタンス作成 作成した AMI を元に、クライアントごとのインスタンスを作成します。なお、インスタンス作成は Terraform や CloudFormation などは使わず、AWS CLI を利用したスクリプトを作成して実行しています。 インスタンス作成スクリプトはこのような流れの処理となります。 引数でクライアント識別 ID やその他サーバアプリケーションセットアップに必要となる環境変数を指定 AWS CLI で EC2 インスタンス作成 引数で指定された環境変数を AWS CLI でパラメータストアに登録 インスタンス作成 以下のように、 aws ec2 run-instances コマンドを使用し、Tag にクライアント識別 ID を指定して作成しています。 ここで指定したクライアント識別 ID を元にパラメータストアから自分用の環境変数を登録/取得したり、Private DNS 用のドメインに使用します。 aws ec2 run-instances \ --image-id ${ AMI_ID } \ --key-name ${ KEY_NAME } --region ${ REGION } \ --subnet-id ${ SUBNET_ID } \ --security-group-ids ${ SECURITY_GROUP } \ --user-data file:// ${ USER_DATA } \ --instance-type ${ INSTANCE_TYPE } \ --tag-specifications "ResourceType=instance,Tags=[{Key=ClientId,Value=${ CLIENT_ID }}]" \ --iam-instance-profile "Arn=${ SERVICE_ROLE }" user-data には初回起動時に実行したいスクリプト（Packer でビルド時にコピーしておいたスクリプト）を指定しているだけとなります。 #!/bin/bash /home/hoge/scripts/bootstrap.sh パラメータストアに環境変数登録 使用する環境変数は、Key は共通ですが値がクライアントによって異なります。そのため、HOGE という Key を使用する場合、 <クライアント識別 ID>.HOGE という形式でパラメータストアに登録しています。 （注. パラメータストアに 階層やタグ付けがサポートされた らしく、このあたりの構成は今後見直す予定です） 登録は aws ssm put-parameter を実行します aws ssm put-parameter \ --name ${ KEY } \ --value ${ VALUE } \ --type ${ PARAMETER_TYPE } \ # String、SecureString など --overwrite これでクライアントごとの EC2 インスタンスが作成、起動されます。次にインスタンス起動時の流れについてです。 EC2 インスタンス起動 起動時は、初回起動と毎回起動でそれぞれ以下のような処理を行います。 初回: パラメータストアから自身に関連する環境変数を取得し、サーバアプリケーションのセットアップ 毎回: 自身の内部 IP を Route53 の Private DNS に登録/更新 内部 IP は固定しておらず起動時に割り振られるため、毎回更新するようにしています。 それではそれぞれの内容について見ていきます。 パラメータストアから環境変数取得 登録時の内容で記載しましたが、環境変数は <クライアント識別 ID>.HOGE という形式で登録しています。そのため、まずは自身のクライアント識別 ID を判定した後に必要な環境変数を aws ssm get-parameters で取得します。 # 自身のインスタンス ID をメタデータから取得 INSTANCE_ID =$( curl -s https://169.254.169.254/latest/meta-data/instance-id ) # クライアント識別 ID をインスタンス作成時に指定した Tag から取得 # (describe-instances の filter に自身のインスタンス ID を指定) CLIENT_ID_TAG =$( aws ec2 describe-instances \ --region=${ REGION } \ --filters "Name=instance-id,Values=${ INSTANCE_ID }" \ | jq -r '.Reservations[].Instances[].Tags[] | select(.Key == "ClientId").Value' ) # 環境変数を取得 # タイプを SecureString にしている変数もあるため、一律 --with-decryption オプションを指定している HOGE =$( aws ssm get-parameters \ --name "${ CLIENT_ID_TAG }.HOGE" \ --with-decryption --region ${ REGION } \ | jq -r ".Parameters[].Value" ) export HOGE =${ HOGE } 内部 IP を Private DNS に登録 最後に、Proxy 層から Private DNS で名前解決できるように自身の IP を Route 53 に登録してやります。 なお、Route53 には事前に対象の Hosted Zone を Private Hosted Zone for Amazon VPC タイプとして登録しておきます。ここでは例として Domain Name を local とします。 EC2 インスタンスから登録される RecordSet は以下の形式とします。 Name: <クライアント識別 ID>.local Type: CNAME Value: EC2 インスタンスの内部 IP これらを行うスクリプト例は以下となります。 # 内部 IP を取得 # (describe-instances の filter に自身のインスタンス ID を指定) PRIVATE_IP =$( aws ec2 describe-instances \ --region=${ REGION } \ --filters "Name=instance-id,Values=${ INSTANCE_ID }" \ | jq -r '.Reservations[].Instances[].PrivateIpAddress' ) # Route53 の登録先 Hosted Zone ID を取得 # SEARCH_KEY は今回の例でいうと 'local.' になります HOSTED_ZONE_ID =$( aws route53 list-hosted-zones \ --region=${ REGION } \ | jq -r ".HostedZones[] | select(.Name == \" ${ SEARCH_KEY } \" ).Id" ) # この後の登録コマンドで指定するための定義ファイル # 毎起動時の登録用（IP が変わるため）に、Action には 'UPSERT' を指定 RECORDSET_FILE = "/tmp/create_recordset.json" cat << EOT > ${ RECORDSET_FILE } { "Changes": [ { "Action": "UPSERT", "ResourceRecordSet": { "Name": "<クライアント識別 ID>.local", "Type": "CNAME", "TTL": 300, "ResourceRecords": [ { "Value": "${ PRIVATE_IP }" } ] } } ] } EOT # 作成した定義ファイルを指定し、Route53 に登録 aws route53 change-resource-record-sets \ --hosted-zone-id ${ HOSTED_ZONE_ID } \ --change-batch file:/// ${ RECORDSET_FILE } 実行するステップはやや多いですが、このような構成をとることで VPC 内ではドメイン指定でのアクセスが可能となるため、IP を意識する必要がなくなるため柔軟な構成になるかと思います。 今回のまとめ いまさらインスタンス立てるとかめんどくさいなぁ、、、とか思いながら色々調べて構築しましたが、EC2 まわりのサービスも増えてるんだなぁ、なんて感じました（特にパラメータストアはとても便利） パラメータストア以外にも Systems Manager には Run Command や Patch Manager など EC2 インスタンスを管理する上でとても便利な仕組みが揃っていますのでこのあたりも導入していきたいと思います。 余談ですが、Systems Manager の存在は re:Invent 2016 で発表された時から名前だけは知ってましたが、今回の対応するまでずっとオンプレ専用のサービスだと勘違いしてて記憶から消えかけていました。。。 最後に 前編を Proxy 層 （Nginx）、後編を App 層（EC2）について書かせていただきましたがいかかだったでしょうか。 そもそもの要件自体がけっこう特殊だったりもするので、なんでこんな構成に？みたいなとこもあるかも知れませんが、どなたかの参考になれば幸いです。もう少し聞いてみたい、というかたは wantedly の「 話を聞いてみたい 」ボタンからどうぞ。 ※前編をあらためて読みたい方はこちらからどうぞ https://developer.medley.jp/entry/2017/08/24/120000_01 お知らせ メドレーでは、医師たちがつくるオンライン医療事典「 MEDLEY 」、オンライン診療アプリ「 CLINICS 」、医療介護の求人サイト「 ジョブメドレー 」、口コミで探せる介護施設の検索サイト「 介護のほんね 」などのプロダクトを提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。 メドレーで一緒に医療体験を変えるプロダクト作りに関わりたい方のご連絡お待ちしております。 メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp