こんにちは、エンジニアの吉田です。

前回そうだ、HTTP/2に移行しよう(OpsWorks編)の記事を執筆しましたが、今回はその続編となります。 (前回から時間が経ってしまい申し訳ないです汗)

前回はHTTP/2に移行する為にAWS OpsWorksを用いたChef12スタックでの シンプルな環境を構築するところまでお伝えしました。 しかし実際はChef12スタックは、Chef11以前のスタックと違い それまでのレシピの運用方法を変えなければなりません。 今回は、現場でのOpsWorks Chef12スタックにおける課題の解決にフォーカスした実践編となります。

実践編

その1. OpsWorksのChef12スタックでコミュニティクックブックを利用したレシピを実行する

Chef12スタックで最も注意しなければならない点は、レシピを実行する際に 利用するコミュニティクックブックの参照が自動的に行われなくなったことです。 試しにコミュニティクックブックを利用したレシピをそのまま実行しようとしたら 「コミュニティクックブック?そんなの見つからないよ！」と怒られます。

なので解決方法としてはコミュニティクックブックを含んだクックブックアーカイブを事前に作成し s3にアップロードした場所を参照するようにします。

コミュニティクックブックを含んだクックブックアーカイブを作成

[前提条件] アーカイブ作成にはBerkShelfをインストールしている必要があります。 もし無い方はChefDKをインストールするか、もしくはGemでBerkShelfをインストールしてください。 ChefDK: https://downloads.chef.io/chefdk Gem: gem install berkshelf

[手順] 1.　ローカルでクックブックのディレクトリに移動する

2.　berks packageコマンドを実行してアーカイブを作成する デフォルトだとcookbooks-1506749951.tar.gzといったタイムスタンプ付きのアーカイブが出来上がります。 もしファイル名を指定したい場合はberks package {ファイル名}.tar.gzのようにコマンドを実行します。

3.　アーカイブを格納する為のs3バケットを作成する

4.　手順3で作成したバケットにアーカイブをアップロード

AWS CLIのS3コマンドが便利です。 aws s3 cp cookbooks.tar.gz s3://{バケット名}

実行後、S3にアーカイブファイルがアップロードされていることを確認します。

こんにちは、チーム活性化サービス「Goalous」のリードエンジニアを務めている吉田です。

今回はGoalousがHTTP/1.1からHTTP/2に移行した経緯と実際にどのように移行したのかをお話します。

なぜ移行したか

僕達は先月までサービス全体の大規模なパフォーマンス改善を1ヶ月半以上かけて行っていました。

Goalousは以前からレスポンスの悪さがかなり目立っていて、「表示速度が遅い」という意見が多く寄せられていました。 開発チームとしてはユーザーのストレスを軽減してサービスの使い心地を向上させたい、 「サクサク動かせるようにしたい」という思いが前々からありましたが ただ機能追加・改善がどうしても優先的になってしまい手をつけることが出来ずにいました。

しかしサービスを有料化する前にはどうしても対応したかったこともあり、 今年5月にチームの総力をあげてサービス全体のパフォーマンス改善に取り組むことが決定しました。 HTTP/2への移行はそのパフォーマンス改善の一つの取り組みです。 HTTP/2のメリットの詳細は今回は省略しますが、詳しく知りたい方はこちらを参照下さい。

HTTP/2への移行を決めたのは、リクエストとレスポンスの多重化等のメリットを享受したかったのと、他にもう一つ僕達にとって重要な理由がありました。 それはAWSの問題です。

GoalousではAWSのOpsWorks(Chefを使用してクラウドエンタープライズでアプリケーションを設定および運用するための設定管理サービス)を使用しています。

OpwsWorksはOpsWorksスタックとOpsWorks for Chef Automateの二種類があり Goalousで使用しているのはOpsWorksスタックです。

OpsWorksのスタックはChefのバージョンが11か12によって明確に区別されます。 僕達はずっとChef11のスタックを使用していましたが、もうそろろそろChef12にバージョンアップしたかったので 今回のHTTP2/移行が良い機会となりました。

あとはロードバランサーがELBではなくALBじゃないとHTTP/2を使用出来ないので思い切って Chef12+ALBの全く新しいスタックを作ることに決めました。

どう移行したか

GoalousのChefのレシピは残念ながら公開出来ないので、本記事においてはあくまで OpsworksのChef12スタックとALBをどう構成してHTTP/2を実現するか に焦点を絞り、サンプルのChefレシピを使ってミニマムな構成の手順を説明します。

参考：Use Application Load Balancers with your AWS OpsWorks Chef 12 Stacks

Step1.ALB作成

基本的にはAWSの公式ドキュメントに沿って作成します。

ただしステップ 5: ターゲットグループのターゲットを設定するはスキップしてください。 インスタンス作成とターゲットグループへのターゲット登録はOpsWorksで行います。

Step2.OpsWorksスタック作成

OpsWorksのダッシュボードページで、スタック追加ボタンをクリックします。

スタック追加ページに遷移後、まずChef12 Stackを選んだ上で、

こんにちは、平形です。

先日8/24、弊社で4回目の外部向けの勉強会を開催しましたので、その様子をご報告させていただきます。

今回はAWS関連のトピックを私、平形と同じく弊社エンジニアの赤川がお届けしました。

今回４回目となる勉強会も盛り上がりを増してきた事もあり、弊社代表の中村が自ら挨拶を買って出てくれました。

今回もたくさんの方々にご参加いただき、大変嬉しく思っています。

内容

今回は、

• AWSを使っているならOpsWorksでDevOpsしよう！ by 平形
• AWS運用アレコレ by 赤川

の２本立てです。

イベントページはこちらのconnpassページにて

弊社では、AWS, GCP, AzureなどクラウドリソースをMSP事業、自社サービスで積極的に活用しております。今回はその中からAWSについてお話ししました。

今回の勉強会のもう一つの特徴は、スピーカーの２人とも今年第一子が誕生した新生育児パパという事です。育児と仕事の両立をして日々業務に精を出しています。

株式会社ISAOは、そんなイクメンエンジニアを応援しています！

AWSを使っているならOpsWorksでDevOpsしよう！ by 平形

AWSのデプロイサービスの一つOpsWorksについて実際の業務で得た知見を発表しました。

AWS運用アレコレ by 赤川

AWSの障害対応など日々1,000台単位のEC2の運用を行なっている中から得られた運用のコツなどを発表しました。

懇親会の様子

秋葉原名物の万世のハンバーグサンドです。

大変美味しく頂きました。

今回も多彩な領域のエンジニアの方々とお話しでき、有意義な交流会となりました。

どうも。久しぶりです。 デベロッパーの平形です。

このブログに訪れたすべてのエンジニアの方々。 そして、エンジニア以外の方々。

とても感謝致します。 初めに言っておきますが、この記事ではコード、コマンドラインの一切は登場しません。

はじめに

私が今回お送りする内容は本当にスケーラブルな環境の構築、運用を手助けする事ができます。 連載記事で複数回に渡ってお届けしますが、この連載を読み終えそして実践していただければ、あなたは既にスケーラブルな環境で作業を行っている事でしょう。

この連載記事では、順番に必要なツールのインストール、使い方をハンズオン形式でお送りします。 実際に手を動かして実感していただく事がとても意味がある事だと思っています。 この回では、コード、コマンドラインは一切登場しません。次回以降にどんどん出てきます。 その前に**「伝えたい事があるんだ。君の事が好きだから」by小田和正**と叫ばせてください。

この記事は以下の方には不向きです。

• 俺は一生一人で生きていくんだ！と1日1回はトイレで意気込んでいる人。
• 後先の事なんか考えたくない。俺は今を生きているんだ！と週に３回は言っている人。

これらに該当する方。お疲れ様でした。出口はこちらです。

この記事は以下に該当する方に是非読んでいただきたいです。

• 開発者、インフラ担当者の方。
• これから新しいプロジェクトを立ち上げるんだけど、構成どうしようか悩んでる方。
• サーバーの台数が多くなったらどうしよう。と悩んでいる方。
• 開発要員が急に増えたらどうしよう。と悩んでる方。
• DevOpsとかスケーラブルな環境とかに興味があって、でも今ひとつ踏み出せない方。
• 上記を実践してみようとしたけど、挫折してしまった方。
• 開発環境で動いているコードがなぜか公開環境で動かなくて家に帰れない方。
• 本番反映が怖くて会社に行きたくない方。
• サーバーが落ちる事が不安で夜も眠れない方。
• 将来の事を考えると不安で不安で仕方なく、「とにかくもう、学校や家には帰りたくない〜。」by尾崎豊と口ずさんでしまう方。

それでは、夢の扉を開きましょう。

レガシーな開発と運用

• 開発環境、公開環境の構築は、構築手順書を元に手動でインストールしている。
• 公開環境のサーバー増設は１台ずつ手動でキッティングしている。
• パッチの適用、バージョンアップは手動で１台ずつ手順書を元に実行している。
• バージョン管理はしないで各自、修正ファイルをFTPでファイルをアップロードしている。

これらをヒューマンエラーなく、ストレスなく運用できるのはスーパーマンです。 そして、開発、運用メンバー全員が自分と同じスーパーマンでなければいけません。 凡人の僕には無理です。

現代の開発と運用

現代のもの凄い勢いで変化するサービス要求に耐えるには、様々なものを効率化しなければいけません。
素早くリリースしてユーザの反応を見ては仕様を変更してすぐに反映しまたリリースする。といった事も必要です。
近頃、開発運用の自動化は様々なメディアの記事で取り上げられ、賑わっています。 しかし、実際にどこまで自動化ができているのでしょうか？

• バージョン管理
• 環境構築
• セキュリティパッチの適用
• バージョンアップ
• オートスケール
• 自動テスト
• 自動デプロイ
• 開発環境の配布

なかなか全部はできないですよね？ でもやったほうが絶対に幸せになれます。

開発の平形です。

今日は、GitHubでpush時にAWS OpsWorksで自動デプロイする方法をお教えします。

OpsWorksはAWSで提供されているデプロイのサービスです。

＊OpsWorksについては、こちらのサイトが詳しいです。

この話は、OpsWorksにスタックとレイヤとインスタンスが存在する前提です。

OpsWorks自体、最近触ったばかりですが、
デプロイがすごく簡単にできるという事はよくわかりました。

でも、欲張りな僕は、もっと自動化できないのかな？と思ったのです。

普段、ソースはGitHubでバージョン管理しているので、
GitHubにpushしたら同時にデプロイできないのかな？と。

そしたら、ビックリするほど簡単に実現できました。

GitHub側で設定が可能です。
アプリケーションのリポジトリのページの「Settings」

「Service Hooks」

AWS OpsWorks

以下の項目は全て必須なので、全部入力します。

ここで、OpsWorks側の情報が必要になります。

まずは、Stack Idですが、一見これがわかるところが、AWS Managed Consoleの画面上にはありません。
手っ取り早くこれを確認する方法はStackの画面のURLをみる事です。

次にApp Idですが、同じくOpsWorksの画面で、「Apps」=>「アプリケーション名」をクリック

OpsWorks IDがApp Idです。