portal shit!

もうすぐ Ruby 2.5 が出そうだけど、このブログの Ruby のバージョンを 2.4 に上げた。

Ruby 2.4 がリリースされたあとすぐに Lokka を Ruby 2.4 に対応させようと頑張ってみたのだけど、 Ruby 2.4 に上げるためには ActiveSupport のバージョンアップが必要だった。しかし padrino-helper 0.11.4.1 が古いバージョンの ActiveSupport に依存しており、 Ruby 2.4 に対応した ActiveSupport を利用するためには padrino-helper をバージョンアップする必要があった。 padrino-helper をバージョンアップしてみると 0.12 から大幅な変更が入ったようで、ビューの表示がぐちゃぐちゃになった。 layout が適用されず中身の partial ビューだけ表示されたり、 HTML が過剰にエスケープされたり。 padrino-helper は 0.11 時代にあった脆弱性を修正して標準ですべての文字列出力を escape するようになったっぽい。しかし Lokka の方がそれに対応できておらずビューがぐちゃぐちゃになっているようだった。

Lokka はヘルパーメソッドやモデルで HTML を文字列から生成しているところがあって、そういうところをこまめに html_safe していったところ余分なエスケープは解消されていった。利用している gem でも文字列から HTML タグを生成しているところがあったので、そういうところもつぶさに調べていって無心で html_safe したり mark_safe していった。

とりあえずこのブログを Ruby 2.4.2 でしばらく運用してみて問題なかったら Lokka 本体の方に Pull Request を出すことにしよう。

あと今回ついでに CircleCI でテストしてテストが通ったら勝手に Production に deploy されるようにしておいた。 CircleCI ほんと便利。

追記 2017-12-03

Pull Request 出しておきました。

Support Ruby 2.4.2 by morygonzalez · Pull Request #231 · lokka/lokka

Add support for Ruby 2.4 Also dropped Ruby 2.1 support, which have got EOL. Update ActiveSupport to version 4.x Fixes various security issues including below Now no need to escape html manuall...

github.com

以前、 The Old Reader について書いたとき、クローリングが遅くて不満だ、というようなことを書いていた。

The Old Reader はフィードの更新間隔がクソで、プレミアムアカウントのユーザーが登録しているフィードは 30 分おきにフィードをフェッチするとあるんだけど、全然そんなことなくて、平気で 4 時間遅れたりする。偏りがあって、頻繁に更新されるブログのフィードは頻繁にチェックされるけど、頻繁に更新されないブログのフィードはあまりチェックされないみたい。クローラーのつくりとしては正しいのかもだけど、利用者としては不満が残るなぁ。

— The Old Reader - portal shit!

そしたら以下のようなコメントを Pinboard でたまわってた。

フィード・リーダーのクローラーが遅い問題の話。Feedlyもそうだけど、クローラー側のポーリングは4時間ごとくらいで良くて、ユーザー（サービス）側がPubSubHubbbub使って欲しいな。

— https://pinboard.in/u:hail2u/b:e25b4cfe2a4a

確かにその通りなのでこのブログでも PubSubHubbub 使うようにしてみた。 Sidekiq とか入れたら Worker にやらせることできていい感じにできるんだろうけど、とりあえずこんな感じで乱暴に通知してる。

class Entry
  after :save do
    if Lokka.production? && !draft
      system("curl -s https://pubsubhubbub.appspot.com/ -d 'hub.mode=publish&hub.url=https://portalshit.net/index.atom' -X POST")
    end
  end
end

爆速で The Old Reader や Inoreader に更新が反映されることを確認したので Feedly とかでも更新後に即反映されるようになってると思う。

autodoc を導入して Rails プロジェクトで Request Spec を書くと自動的にドキュメントが更新されるようにした。 autodoc 自体は前々職の頃から利用していて大変お世話になっていた。ただ最初の頃は手元で AUTODOC=1 bundle exec rake spec:requests して手動でドキュメント更新していた。ドキュメントが更新されるかどうかは担当者の心がけ次第なのでよくなかった。

前職では CircleCI を使っていて、デプロイや Asset Precompile など CI でいろいろやるのが当たり前だったので、 Pull Request が Merge されたタイミングでドキュメント生成するように .circleci.yml をカスタマイズしてた。

いま仕事しに行ってるところでは .circleci/config.yml を version 2 にしていて、 version 2 からは workflow の概念が導入されたので、頑張ってシェルスクリプトで条件分岐させたりする必要がなくなった。 .circleci/config.yml は以下のような感じになってる。

version: 2

shared: &shared
  working_directory: ~/app
  docker:
    - image: circleci/ruby:2.4.1-node
      environment:
        PGHOST: 127.0.0.1
        PGUSER: username
        RAILS_ENV: test
        REDIS_HOST: localhost
    - image: circleci/postgres:9.6-alpine
      environment:
        POSTGRES_USER: username
        POSTGRES_PASSWORD: pasword
    - image: redis:3.2-alpine

jobs:
  build:
    <<: *shared
    steps:
      - checkout
      # Restore bundle cache
      - &restore_cache
        type: cache-restore
        key: app-{{ checksum "Gemfile.lock" }}
      # Bundle install dependencies
      - &bundle_install
        run: bundle install -j4 --path vendor/bundle
      # Store bundle cache
      - &save_cache
        type: cache-save
        key: app-{{ checksum "Gemfile.lock" }}
        paths:
            - vendor/bundle
      # Database setup
      - &db_setup
        run:
          name: Database Setup
          command: |
            sudo apt install postgresql-client
            bundle exec rake db:create
            bundle exec rake db:structure:load
      - type: shell
        command: bundle exec rubocop
      # Run rspec in parallel
      - type: shell
        command: |
          mkdir coverage
          COVERAGE=1 bundle exec rspec --profile 10 \
            --format RspecJunitFormatter \
            --out /tmp/test-results/rspec.xml \
            --format progress \
            $(circleci tests glob "spec/**/*_spec.rb" | circleci tests split --split-by=timings)
      # Save artifacts
      - type: store_test_results
        path: /tmp/test-results
      - type: store_artifacts
        path: coverage

  generate-doc:
    <<: *shared
    steps:
      - checkout
      - *restore_cache
      - *bundle_install
      - *save_cache
      - *db_setup
      # Generate document
      - type: shell
        command: |
          AUTODOC=1 bundle exec rake spec:requests
      - run:
          name: Setup GitHub
          command: |
            export USERNAME=$(git log --pretty=tformat:%an | head -1)
            export EMAIL=$(git log --pretty=tformat:%ae | head -1)
            git config --global user.email "${EMAIL}"
            git config --global user.name "${USERNAME}"
      - run:
          command: |
            git add doc
            git commit --quiet -m "[ci skip] API document Update

            ${CIRCLE_BUILD_URL}"
            git push origin ${CIRCLE_BRANCH}

workflows:
  version: 2
  build-and-generate-doc:
    jobs:
      - build
      - generate-doc:
          requires:
            - build
          filters:
            branches:
              only:
                - master

master ブランチでのビルドのときだけ generate-doc という job が実行されるようになっている（ master ブランチ以外のビルドではドキュメント生成がスキップされる）。build と generate-doc で重複してる部分が多いので YAML のアンカー機能を使って重複を整理しているけど結構長い。 generate-doc ジョブでドキュメントが生成されると勝手に GitHub の master ブランチに対して push する。このときコミットメッセージに [ci skip] という文字列を付けておけば、 CircleCI はビルドをスキップするので延々とドキュメントの自動更新ビルドが走り続けることはない。

おかげでいまはテストさえ書けば、実際の API と同じフォーマットのドキュメントが自動生成されるのでとても便利になったと思う。

ちなみに JSON Schema というのもあって、これは JSON に仕様を書くとドキュメントやらモックサーバーを作ってくれるものらしい。めっちゃ便利そうだけど、ちゃんと使うのにはそれなりに仕組みを整える必要がありそうで手を出していない。 autodoc の作者の r7kamura さんのブログにも書いてある通り、 autodoc の便利なところは以下だと思う。

実際にアプリが生成した内容からドキュメントを生成するため、実装とドキュメントの乖離が少なく抑えられる。 また、テストを書くことの見返りが増えるため開発者がテストを書くのを推進しやすい。

— 全てがJSONになる - ✘╹◡╹✘

autodoc で master ブランチへの Merge をトリガーにしてドキュメントを自動生成するというポリシーでは、 B/E 側の作業中に F/E の人が API のドキュメントを見られなくて不便だという問題は確かに存在する。しかし JSON Schema で事前に仕様を固めて実装前にモックサーバーやドキュメントを提供できたとして、果たして事前に決めたとおりに B/E も F/E も実装できるのだろうか。きっと作っていく途中で「やっぱりアレはコレに変えたい」みたいのが双方から出てくると思う。

↑の r7kamura さんの記事では他に外の API をモックするダミーサーバーを JSON Schema で作ったりしてる。確かにすでに仕様が固まった外部の何かをモックするサーバーのセットアップなどには便利なのかもしれない。ただいまのところは autodoc での後追いドキュメント自動生成で自分は事足りるかなという感じがしている。

プログラマーの種類、いろいろあると思う。

1. ハッカー
   プログラミングが楽しくて、コードさえ書ければあとは何でもいいという人。
2. OSS プログラマー
   1 と似てるけど、 OSS が楽しくてコードを書いてる人。カンファレンスで登壇したり、技術ブログを熱心に書いたりする。
3. プロダクト指向プログラマー
   開発だけでなく事業の方向性にも口を出したい人。社長が死んだらいつだって代替ができる、というような気概の人。
4. サラリーマンプログラマー
   プログラミングは仕事のためと割り切っていて、余暇には一切コードを書かない人。

1 〜 4 のどれか一つに綺麗に分類できるというものではなく、 1 かつ 3 とか、 3 かつ 4 とか、複数にまたがる人もいる。

職業プログラマーになりたての頃、サラリーマンプログラマーしかいない環境で働いて早くそこを抜け出したいと思っていた。プログラマーは会社の最下層で、プロジェクトマネージャーや営業が偉かった。プログラマーの人たちは仕事のために仕方なくプログラミングしてた。

それが嫌で余暇でもコード書くような人たちがいる職場に移ったけど、そこではハッカーや OSS プログラマーがよいプログラマーの代表とされていた（と思う）。自分もそういうのを目指し OSS カンファレンスに登壇したり技術的に中身のあるブログ記事を書いたりしたいと思ったけど、なかなかよいコードは書けないし、結婚して所帯を持つと町内会の草むしりや廃品回収、町内の運動会のテント設営、審判にかり出され、またあるときは子どもの幼稚園に夫婦そろって呼び出されて「お前らは夫婦そろって人間の屑以下だ、心を入れ替えるか幼稚園を辞めるかどっちか選べ」と説教されるなど多忙を極め、勉強会で話したりブログ記事を書いたりということが難しくなった。

一時期は自分は凡人プログラマーなんだろうなぁ、かつて忌み嫌っていたサラリーマンプログラマーと同じなのかなぁ、と将来を悲観していた。この頃は技術的な伸びしろがなくなって学ぶことに対する意欲が失せてしまっていた。

ただ、仕事で失敗プロジェクトを担当してつらい目に遭うことが多く、チームで仕事することだとか、失敗からどう学ぶかとか、その手のことに関してはそこそこ知見が貯まっていった。どうすればチーム開発はうまくいくのか、どういう風に情報を共有すればいいのかなどなど。業務改善のためにちょっとしたスクリプト書いたり、ぶっ壊れて動かなくなってる hubot スクリプトを直したり、 CI のセットアップを頑張ったりと、エンジニアチーム全体の生産性を上げるような落ち穂拾い業務みたいなタスクも好きだった。

いまは自分はチーム開発プログラマーなんだろうなぁと思う。ハッカー気質は皆無じゃないけどそこそこ、 OSS へのコントリビュートも気が向いたときに、プロダクトのことを気にする気持ちもある。どれも中途半端で単独では生産性高くないけどチームで仕事をするときに効能を発揮するタイプ。こんな風に自分が適している役割が分かると仕事がやりやすくなるし、目指すべき方向性のようなものが明確になって将来のことを考える上でも役に立つ。

ベンチャー企業で働く場合は自分のマインドやスキルセットが会社のステージにフィットすることも大事だと思う。もともとはベンチャー企業でも成功して上場しているような会社だとデプロイ時にハンコリレーなどがあってやるべきことをやるべきときにババッとやるのが難しい。そういうのは自分には向いてない。一方で起業したばかりの小さなスタートアップも、自分のような最初から綺麗なコードを書こうとするプログラマーはきっとフィットしない。起業したばかりのスタートアップでは自分たちの事業が社会から求められるかどうか不透明なので、そんな状態でテストがどうだとか CI がどうだとかチーム体制がどうだとかを言うようなプログラマーは必要ない。汚くてもクソコードでもテストコードなんて存在しなくてもいいからとにかく金を生み出すコードを素早く書ける人が向いている。

その意味でいまいる会社は創業当初の価値仮説の検証は済んでいて、これからいかに事業を伸ばしていくかというステージに入っているので、ちゃんとテストを書いたり、 CI を導入して継続的インテグレーションに努めたり、デプロイをいい感じにしたり、情報共有ツールを導入したり、開発チームの組織体制を云々したりといった部分で価値を発揮しやすい。

一握りの本当に優秀なソフトウェアエンジニアってのは受託会社だろうが事業会社だろうがベンチャーだろうが大企業だろうがどこにいたって価値を発揮できるのかもしれない。しかし自分のようなすべてにおいて中途半端なプログラマーは、自分に何ができるのかを理解し自分を必要とする規模とステージの会社を見つけてそこの門を叩くのがよいと思う。もちろん、事業に共感できるとか、チームメンバーとの相性も大事だけど、事業に共感できてもチームのメンバーがいい人ばかりでも、会社の規模やステージが自分を必要としなければ価値を発揮することは難しい。

関連してそうな記事

良いエンジニアの定義

転職後、エンジニアとしての能力不足を実感した。良いエンジニアには技術力だけでなく、プロジェクトマネジメント力や問題解決能力も必要だと考える。来年はこれらのスキル向上を目指す。

portalshit.net

ECS 化していたブログをさくら VPS に戻した。理由としてはお金が高かった。普段、 S3 と Route 53 に払ってる金額の 20 倍くらいの金額になって少ない小遣いでは払えないと思ったので VPS に戻した。ただ AWS で運用して勉強になった点もあった。

まず ECS での運用について知見が得られたのがよかった。 deploy するためには docker build と docker push が必要で、最初はちょっとした修正のためこれやるのは大げさだと思ったが、慣れればそんなでもなかった。ただイメージのビルドをどこでやるかは考えといた方がよさげ。自宅だと高速な光回線があるからよいけど、実家やどこか旅行に行ったときに image をビルドして ECR にプッシュするのはつらい。 GitHub に git push する度に CircleCI でビルドされるような体制を構築する必要があると思った。

CloudFront をウェブアプリケーションの前段に挟む、というのもやってみたけどこれもよかった。 Rails なら Asset Precompile によって静的なファイルへのリクエストはウェブアプリケーションまで届かないようにするのを良くやると思うけど、 Lokka は Sass や CoffeeScript を動的にコンパイルしてクライアントに返すので、 CSS や JS などへのリクエストにも puma のプロセスが消費されてエコではなかった。 VPS 運用時には Nginx を前段に入れて、画像やコンパイル済みの JS / CSS ファイルへのリクエストは puma にプロキシせず直接返していたが、 ECS 化したときに Nginx を挟まなくなったので CloudFront を入れて画像や JS / CSS へのリクエストをキャッシュするようにしてみた。

すると puma の負荷が低下し、 New Relic の Appdex が 0.95 前後だったのが 0.99 になった。 ECS で利用していた EC2 コンテナは t2.micro でしょぼいのでサーバーのスペックアップで改善されたわけではない。ということで VPS に戻すときにも Nginx の proxy_cache を使って Sass や CoffeeScript から動的にコンパイルされる CSS / JS をキャッシュするようにしてみた。さすがに CDN のような配信の最適化は実現できないが、以前よりかはかなりましになるはず。

なおセッションを有効にした Rack アプリで Sass や CoffeeScript を動的にコンパイルすると Set-Cookie ヘッダーがセットされてしまう。 Nginx の proxy_cache は Set-Cookie ヘッダーがセットされてるとキャッシュをしないので、

proxy_ignore_headers Set-Cookie;
proxy_hide_header Set-Cookie;

などとしてやる必要がある。

今後仕事でも ECS 化を行う予定があるので得られた知見を有効活用していきたい。

Podcast を聞くのには Marco Arment の Overcast を使ってたんだけど、最近「 Internet Connection を確認しろ」みたいなメッセージが出てエピソードの一覧を取得できないことが何度かあってストレスに感じたので Castro に変えてみた。 Overcast は独自のサーバーサイドアプリケーションがあってそこと通信してるので、 overcast.fm の調子が悪くなると新しいエピソードをダウンロードできなくなる。 Castro や Apple の Podcast アプリだと iTunes から直接ダウンロードしてるので iTunes のサーバーがダウンしない限りエピソード一覧を取得できないということは起こらない。

エピソードの再生クオリティに関してはやはり Overcast の方がすばらしい。無音部分のカットや賢い倍速再生はやはり Overcast ならではだと思う。 Castro で再生してみて無音部分は結構気になることに気がついた。

一方でエピソード一覧の UI などは Castro が優れていると思った。以前聞いたエピソードを聞き返したいとき、 Castro は年月でエピソードがグルーピングされるので心理的に探しやすい。

Overcast の方は雑然とエピソードが羅列されているだけなので探しづらい。

プレイリスト

Castro はプレイリスト機能が前面に出ていて、基本的にリストに聞きたいエピソードを登録して聞くというスタイルになる。次に聞くエピソード、過去に聞いたエピソードのヒストリー機能もあるので、昨日聞いたあれをもう一度聞きたいというときにも便利。 Overcast にもプレイリストはあるが存在に気がつきづらい。次々に新着のエピソードを聞いていくという使い方には向いてるが、過去のエピソードを掘り出して聞くときには Castro の方が優れている。

再生中画面

再生中の画面に関しては Overcast の方が良い。カバーアートをスワイプするとショーノートとチャプター一覧を行き来できるのも便利。

Castro はショーノートと再生位置の切り替えは▽のトグル式で、しかも再生位置確認画面は SoundCloud のように波形表示される。

正直こんなのは必要ない。僕は興味のない話題はスキップするので Overcast で聞いているときはショーノートを見ながら再生位置スライダーを動かしてスキップしたりするが、 Castro ではショーノートを表示している状態では再生位置スライダーが表示されないので 30 秒早送りボタンを連打するしかない。

結論

再生中の画面の UI には問題があるが、全体的なルックアンドフィールは Castro の方が優れていると感じた。配色を含めたデザインは Castro の方が使いたいと思わせられる。ちゃんとデザイナーによってデザインされている感じ。 Overcast の方はエンジニアが片手間でデザインした感がぬぐえない。

Overcast に不満がある人、過去エピソードをよく聞く人は Castro を試してみるといいと思う。

ブログを Docker 化して AWS ECS で運用するようにした。

なぜ Docker 化したか

• 仕事で Docker を使う機会が増え知見がたまってきた
• 仕事では Production 投入はできていないので個人ブログで Production 投入して知見を得ておきたかった

どうやったか

ローカルセットアップ編

• Dockerfile & docker-compose.yml を作成した
  • Alpine Linux を使ってなるべくイメージを小さくする
• Gem::LoadError 問題
  • Lokka の Gemfile には動的な読み込みを行っている部分があるため、 Dockerfile で単純に COPY するだけでは Gem::LoadError になってしまう。
    • Lokka のプラグインは Gem 化されておらずリポジトリ内に含める形式
    • プラグイン側で必要な gem はプラグイン内に Gemfile を配置して宣言する形式
    • Lokka 本体の Gemfile には Dir["public/plugin/lokka-*/Gemfile"].each {|path| eval(open(path) {|f| f.read }) } のようなコードがあって強引に eval で内容を取り込んでいる
  • 対策
    • Gemfile.docker を用意する
    • Gemfile.docker を生成するためのシェルスクリプトを用意して実行する
    • Dockerfile の COPY は以下のようにする
    • COPY Gemfile.docker /app/Gemfile
• 他、 MySQL のコンテナを追加して手元でアプリが起動するところまでは確認済み

Production セットアップ編

• ECR にリポジトリを作成し image を push （公式のチュートリアル通りにやればできる）
• ECS にサービスやターゲットグループ、タスクの作成なども指示通りに行う
  • 土台となる EC2 インスタンスは手動で作るのではなく、 ECS の画面でポチポチやると勝手に作られる
  • 詳細コンテナ設定でエントリポイントを入力する欄に、 Dockerfile と同じように文字列で書いていたらコンテナが起動せずハマった
    • カンマ区切りで書かないといけないらしい
    • puma を起動したかったら bundle exec puma ではなく、 bundle,exec,puma というように書かないといけない
• 諸々設定を済ませたらロードバランサー（ ALB ）を EC2 のパネルで作成してターゲットに Docker コンテナが動いている EC2 インスタンスを指定する
  • ECS の用語やサービス構成に慣れるのに時間がかかるが、歯を食いしばってがんばるしかない
• DB に関しては RDS を使うことにした
  • 稼働中の VPS サーバーで mysqldump -ufoo -p db_name | mysql -ubar -p db_name -h foo.bar.ap-northeast-1.rds.amazonaws.com みたいな感じで雑に流し込んで移行する
• ECS は VPC でしか使えないので、 VPC に慣れてない人は VPC に慣れるところから頑張るしかない
• セキュリティグループの設定なども必要になるので頑張って下さい
• Nginx を利用しないので SSL の復号を ALB で行う必要がある
  • ACM で無料で証明書を発行できるのを知らず、 Let's Encrypt の証明書を取り込んで使う
• ここまでで一旦公開

運用して気づいた問題点

• サイトが 503 や 504 になる
  • Docker コンテナがすぐ死ぬ
  • ALB から切り離されることしばしば
  • VPS 時代は Nginx に静的ファイルの配信をまかせていたが、 Nginx を挟まなくなったので puma が担当することになりアプリの負荷が高まったのではと推察
    • CloudFront を挟んでいい感じにキャッシュしてもらい、静的ファイルの配信は CloudFront にまかせることに

CloudFront 導入編

• ALB で使っているのとは別に SSL 証明書を取得する必要がある
  • CloudFront <-> ALB 間の通信を HTTPS で行うため
  • Route53 で ALB に割り当てている A レコードをサブドメイン付きの別のものに変更
  • ALB 用にはワイルドカード証明書を使う（無料で証明書取得できる ACM 最高）
  • Let's Encrypt の証明書を使うのはやめ、ルートドメインの証明書も ACM で取得して CloudFront に設定
• 動的コンテンツ（ HTML など）はキャッシュしないようにしないといけない
  
  • 当初、設定がうまくいっておらず、以下のような問題が発生
    • POST, PUT, DELETE できない
    • Cookie が origin に転送されずセッションが維持できない
    • クエリストリングが無視されてしまい、ページ検索などができない

所感

• 体感的にサイトの読み込みがチョッパヤになった
• CloudFront 導入したが、まだ 503 にはなる
  • そもそもインスタンスを良いやつに変えないとダメなのかもしれない
  • タスク数を増やしてクラスタリングするなどいろいろ試してみる
    • クラスタリングするためには Cookie セッションではなく Redis や Memcached などをセッションストレージに使う必要が出てくる…
• Deploy だるい問題
  • cap deploy しなくなり、イメージをビルドして push する感じになる
    • Alpine Linux でもそこそこイメージサイズはでかくなるので貧弱な回線では docker push にめっちゃ時間かかる
  • ECS 側でもサービスを更新するなどの作業が発生
    • Blue / Green Deployment できるがポチポチ作業が発生するのがだるい
    • Rails を運用する場合は migration なども発生するのでうまいことやる必要あり
  • git commit しなくても作りかけのコードの状態で docker-compose build してしまいがちになり、リポジトリのコードと動いてるコンテナイメージの間に差分が発生してしまいそう
    • ちゃんと CircleCI などを導入してイメージのビルドとプッシュは CI サービスでやる、というような運用にしないと破綻しそう
• 手順書問題
  • こんな風にブログを書いて雑な手順書を作成するようではいけない。 Terraform 化しないと破滅する。
• Lokka は CMS for Cloud です
  • git push heroku master するだけで使えることが売りの Lokka を AWS のガチな構成で運用するという皮肉
• お金高い
  • 毎月 3000 円くらいかかる感じになりそう。 VPS は年払いで 16000 円くらいなのでだいぶ高い。払えなくなったら VPS に戻しそう。

謝辞

r7kamura さんの amakan Docker 化の一連の記事と Classmethod 社の ECS 関連の記事には大変お世話になりました。

• amakanの開発環境をDockerに移行した - ✘╹◡╹✘
• amakanの本番環境をDockerに移行した - ✘╹◡╹✘
• Amazon ECSのELB構成パターンまとめ(ALB対応) ｜ Developers.IO
• CloudFrontとELB間をSSLで通信させる ｜ Developers.IO