JAWS DAYS 2021でハンズオン講師をやります

はじめに

3月20日に開催されるJAWS DAYS 2021で、ハンズオンの講師を務めることになりました。

目次

JAWS DAYS 2021とは

JAWS-UG(AWS User Group - Japan)という、日本全国に70以上の支部を持つAWSのユーザーグループがあります。

JAWS-UGでは各支部ごとにそれぞれ独自の勉強会を開催しているのですが、JAWS DAYSはこの各支部が結集して開催する年に一度の大イベントです。

様々なセッションが予定されていますが、その中に初心者向けのハンズオン枠があります(以下リンク先タイムテーブルのTrack ID : F)。

そのハンズオンのひとつを私が企画から担当することになりました。

ハンズオンの内容

AWSの仮想ファイアウォールであるセキュリティグループに関するハンズオンとなります。

以下の3つのケースを、セキュリティグループの仕組みを理解しながら実際に設定していく内容となっています。

  • IPアドレスを限定せず、Webサービスを利用させるケース
  • 特定のIPアドレスに対してのみ、Webサービスを利用させるケース
  • 特定のリソース同士を相互に通信可能とさせるケース

なぜセキュリティグループか

セキュリティグループはAWSの中で使われることが非常に多いリソースのひとつかと思います。

こういった、誰もが使うリソースの基本を初心者目線で学ぶハンズオンをやってみてはどうかと思い、今回企画しました。

当初は内容的にちょっと地味すぎるかなとも思ったのですが、AWSを初めて導入しようとしているような企業を相手に普段お仕事をされている方からは

「AWSを使いたいと思っているけれど、想像以上にAWSのことを知らないお客様は多い。非常に良い企画。」

と言っていただけたこともあり、今回テーマをセキュリティグループの基礎としました。

申し込み方法

以下のサイトから申し込めます。もちろん無料です。

なお、このハンズオンの参加にあたっては、JAWS DAYS 2021本体への申し込みも必要となりますのでご注意ください。

JAWS DAYS 2021本体への申し込みは以下で受け付けています。こちらも無料です。

その他のハンズオン

セキュリティグループ以外にも以下のようなハンズオンが予定されています。

気になるものがあれば、ぜひ申し込んでみてください。

終わりに

このハンズオンを通じて、セキュリティグループの基本的な使い方を学んでいただければ幸いです。

参加をお待ちしています!

私のAWS認定ソリューションアーキテクトアソシエイト(SAA)試験対策

はじめに

先日、AWS認定ソリューションアーキテクトアソシエイト(SAA)を受験し、合格しました。

合格ラインは1000点中720点ですが、821点でした。

本記事では合格に向けて私の取った試験対策を解説します。

目次

結論

www.whizlabs.com

  • 本番と同じく65問から構成される練習テスト(Practice Test)が計7セットあるので、8〜9割正答できるまで繰り返し解く

  • 最終テスト(Final Test)で8割解けたら本番を受験する

前提

私自身はAWSの実務経験が1年強あり、全くのAWS未経験からこの問題集だけ勉強して合格したわけではありません。

まだAWSを触った経験の無い方は、以下のような書籍等で基礎的な事項を学習した上で本記事で紹介する問題集に取り組むようにしてください。

blog.takuros.net

Whizlabsの良いところ

試験対策をする上で、私がWhizlabsで良いと思ったところは以下になります。

1. 安価に大量の練習問題が手に入る

約10ドルで700問以上もあります。内訳は以下の通りです。

  • 本番と同等の65問構成のテストが7セットあり、計455問

  • 上記とは別に分野別問題集が220問

  • 最終テストがさらに65問

2. 英語対応力が身に付く

本番のAWS認定試験では日本語か英語かを選択でき、途中でいつでも変更できます。

ただ、日本語で出題される問題は稀に誤訳と思われるものがあり、そういった場合は英語に切り替えて問題を読むことになります。

Whizlabsを使って普段から英語のみで問題を解く習慣を付けておくと、本番でも焦らずに対処できるかと思います。

3. 練習モードを使って効率的に学習できる

具体的なやり方は後述しますが、練習モードというものがあり、こちらを使って効率的に学習できます。

(Whizlabsは単なる問題集ではなく、学習の履歴が記録されるなどオンライン学習サイトとして様々な機能があります)

Whizlabsの良くないところ

逆にWhizlabsで不満に思うところは以下になります。

1. 全編英語なので取っつきづらい

英語であるメリットの裏返しとなりますが、日本語に対応していないので学習サイトとしての機能を把握するのにも最初は少し苦労するかもしれません。

2. 右クリック禁止のため翻訳サービスを利用しづらい

問題のコピペを容易にできないようにするためか、右クリック禁止となっています。

ただ、これは解除可能です。具体的なやり方は後述します。

3. Webサービスとしてのレスポンスが遅い

全体的に画面レスポンスがもっさりしています。

ただ、勉強する上でそこまで支障は無いかと思います。

練習問題が一部古いことに対する注意点

AWSの各サービスは日々仕様がアップデートされるので、問題もこれに追従していく必要があります。

Whizlabsの問題も2020年版を謳っており、できる限りの最新化はされているようです。

ただ、S3に関する練習問題ではS3の特徴として「結果整合性」が正解になっているなど、現在の最新仕様にそぐわない場合もあります(現在の最新仕様では「強力な書き込み後の読み取り整合性」となっています)。

まあ、これに関しては2020年12月に発表されたばかりの仕様なので仕方ないかもしれません。

aws.amazon.com

Udemyの問題集について

似たようなコンセプトの商品として、UdemyにもAWS Certified Solutions Architect Associate Practice Examsという問題集があります。

www.udemy.com

定価は3,600円で、セール時の価格だと1,500円前後になります。

プラットフォームはUdemyですが中身に動画は無く、問題集のみとなります。計65問の練習テストが6セット入っています。

こちらも購入してみたのですが、Whizlabsの練習問題と比べて発展的・応用的な問題が多い印象です。

断片的な知識だけでは解けない良問ばかりで非常に勉強にはなるのですが、実際の本番の試験ではこのUdemyの問題集ほど応用的な問題はさほど出題されなかった印象です。

その他、個人的に不満に思ったところは以下になります。

  • 1問づつ答えを確認できるような練習モードが無く隙間時間に勉強しづらい

  • 計65問の練習テストは実施するたびに出題順がシャッフルされるので、過去正答済みの問題を無視して取り組むということがやりづらい

とはいえ、これらの問題を7割程度解けるようになれば本番でも充分合格できると思うので、こちらのUdemyの問題集を既に購入済みの人が、今回おすすめしているWizlabsの問題集をわざわざ追加で購入する必要は無いかと思います。

Whizlabsでのおすすめの学習方法

ここからはWhizlabsでのおすすめの学習方法を解説します。

1. 時間無制限の練習モードを使う

Whizlabsでは一連の練習問題を開始する際に、通常モードにするか練習モードにするかどうかを選択できます。

通常モードだと本番の試験さながらに時間制限があり、また全ての問題に回答してSubmitボタンを押すことで初めて正答・解説を見ることができます。

これに対し、練習モードでは時間無制限で、1問ごとにいつでも正答・解説を見ることができます。

練習モードを選択するには問題を開始する際に表示されるポップアップにStart quiz as prctice modeというチェックボックスがあるので、これにチェックします。

2. 1問ごとに答えを確認する

前述の通り練習モードにしたら、問題を1問解くたびに答えを見て正解か不正解かを確認するようにします。

答えはShow Anserボタンを押すことで表示されます。

3. 正解であれば問題に印を付けて二度とやらない

ここで答えを確認し、もし結果が正解であればもう二度とやらないで済むよう、問題に目印を付けるようにします。

Mark for reviewというチェックボックスにチェックを入れると、問題一覧でその問題は赤く表示されるようので、これを目印にします。

この印機能は、本来は時間制限のある試験の中で後で見返すために付ける印なのですが、今回は正答済みであることを記録するために使っています。

4. 不正解であれば解説を読む

答えを確認し、不正解であれば解説を読んでください。

なお、解説も英語です。

翻訳サービスを使うためにもし右クリックが必要であればChromeのメニューからデベロッパーツールを開き、consoleタブで以下を入力してください。右クリックできるようになります。

document.addEventListener('contextmenu',function(e){e.stopPropagation();},true);

5. 不正解の選択肢がなぜ不正解か、その根拠についても理解する

各解説には多くの場合、正解の選択肢が正解である理由のほかに、不正解の選択肢がなぜ不正解なのか、その根拠についても書かれています。

ここも目を通すことでより理解が深まり、1問から多くの知識が得られるようになります。

6. サービスそのものの知識が無ければググってクラスメソッドさんの記事を読む

解説を読んだとしても、問題や選択肢で登場する各サービスについての知識がそもそも無ければ一度に理解することは難しいかと思います。

こういった場合は、そのサービス名でググってください。

AWSの公式ドキュメントの他に、Developers.IOというクラスメソッドさんのオウンドメディアの記事が検索にヒットする場合があります。

dev.classmethod.jp

わかりやすく、また内容の精度も高いので、これらの記事を参考に各サービスを理解するようにしてください。

7. 隙間時間を見つけて中断・再開を繰り返し正答率8〜9割を目指す

練習モードを中断する際は、画面右上のバツボタンを押します。

すると、正答済みの問題に付けた「印」が記録された状態で中断することができます。

65問目など最後の問題のSubmitボタンを押してしまうと中断ではなく終了扱いとなり、印がリセットされてしまうので注意してください。

再開する際はResume quizボタンを押します。

以上の方法で、隙間時間など見つけて繰り返し問題に取り組み、8〜9割の問題に印が付くことを目指してください。

終わりに

以上、私流のAWS認定ソリューションアーキテクトアソシエイトの試験対策でした。

合格を目指す方の参考になれば幸いです。

私もまた別のAWS認定試験に挑戦するつもりです。一緒に頑張りましょう!

Web系エンジニアに転職して約2年働いて退職した話

はじめに

2019年に転職してWeb系のエンジニアとなり、約2年働いた後、今月で退職しました。

本エントリではその振り返りと、退職後のこれからについて触れます。

目次

振り返り

まずは、退職した企業の振り返りから。

どんな業態の企業だったか

Webサービスを複数持ち、自社の正社員エンジニアにてそれらの開発・保守を行っている企業です。

よくWeb系自社開発企業、受託、SESなどと分類されることがありますが、そのうちのひとつ目にあたる企業になるかと思います。

どんな仕事内容だったか

入社後、最初の4ヶ月はLaravelとVue.jsによるWebアプリケーションを開発するチームにて社内向けやtoB向けの機能追加や改善などを行いました。

その後はSREチームへ異動となり、以降は自社の全サービスのインフラ(AWS)構築やCI/CD整備などを担当しました。

働いてみての所感

とても恵まれた環境で、この企業でWeb系のエンジニアとして働けたことは本当に良かったと思っています。

具体的には以下の3点になります。

  • 人が良かった
  • スキルを高められる環境だった
  • 裁量があった

1. 人が良かった

全体的に穏和な人が多く、約2年働いた中でギスギスした雰囲気の中で仕事をするようなことはありませんでした。

社内のエンジニアは書籍Team GeekにあるHRT

  • Humility(謙虚)
  • Respect(尊敬)
  • Trust(信頼)

を大事にしており、こうした点は日々のコードレビューでの指摘、Slackでのテキストベースのやり取り、障害発生後の振り返りの場(ポストモーテム)での各エンジニアの行動にも表れていました。

責めたり、詰めたりするような行動は忌避されていました。

2. スキルを高められる環境だった

最初に配属されたWebアプリの開発チームでは毎日のようにコードレビューを受けていましたが、LaravelやVue.jsについて深い知識を持ったエンジニアからの的確な指摘により鍛えられました。

また、次のSREチームでも、いまは離任していますが長年のインフラ経験と最新のクラウドの知見のあるリーダーのもと、幅広い仕事を担当させてもらいました。

両チームで共通していたこととして、わからない点は遠慮無く聞くことのできる雰囲気が醸成されていて、安心感を持って日々スキルを高めていくことができました。

3. 裁量があった

個々のレビュー指摘はしっかりありますが、一方で案件の方針や進め方に関しては裁量を与えられ、自由にやらせてもらえていた気がします。

こちらの意見や提案も採り入れてもらえました。

創意工夫が活かせる点は、やりがいをもって仕事に臨むことができました。

退職に至った理由

このような恵まれた環境で働くことができていたのですが、2年が経過し様々な環境の変化のある中で、これからを考えて退職することにしました。

理由はいくつかあるのですが、最も大きいものとして、自分の目指す方向(SRE)について、さらに高度な知見・スキルを身に付けて組織を牽引できるような人間へとなりたいという思いがあり、そのためにはより先進的な取り組みを行っている組織に飛び込むのが一番だという考えに至ったからです。

この辺りは話し始めると非常に長くなるので、私のことを知ってる方は興味があればオンライン飲みにでも誘ってください。色々語らせていただきます。

退職後について

現状よりも一段規模の大きいWeb系の自社開発企業にて、来月からSREの一員として働きます。

その企業はSREに限らず、非常にレベルの高いエンジニアが多数在籍しているので、いまの自分がやっていけるかどうか不安もありますが、約2年前にWeb系にキャリアチェンジした時の気持ちを思い出して、精一杯頑張っていきたいと思います。

最後に

今回の突然の転職では色々な方にご迷惑をお掛けしましたが、応援もしていただき、本当にありがとうございました。

これからもどうぞよろしくお願い致します。

AWSの予測請求額を通知して想定外の費用発生を防ぐ

はじめに

昨年末、勉強のために個人のAWSアカウントにとあるAWSリソースを一時的に作成しました。

その後、このリソースは不要になったのですが、削除することを忘れ、そのまま年を越してしまいました。

年末年始はAWSを触ることも無くのんびりと過ごしていたのですが、1月3日にAWSから以下のメールが届きました。

月末の予測請求額が28ドルであることを通知するメール

「28ドル!」

これは実際に28ドルの請求が発生したわけでなく、いまのAWS利用のペースで月末を迎えると今月の請求額が28ドルになることを予測して通知してくれたメールです。

このメールを受けて私は自分のAWSアカウント内に放置している課金対象のリソースが無いかを調べ、その存在に気付いて削除しました・・・。

AWS Budgetsについて

上記のメールはAWS Budgetsという機能により送信されたものです。

AWSアカウントを個人で運用して勉強中の初心者の中には、私と同様に不要リソースを削除し忘れた経験のある方もいるかと思います。

本記事ではAWS Budgetsを使って、請求額の予測が一定以上になったら通知する方法を解説します。

非常に簡単ですので、こうした設定を行なっていない人はぜひやってみてください。

AWSのベストプラクティスであるAWS Well-Achitectedにおいても、想定外の費用発生を通知するよう設定しておくことはコスト管理の基本であるといった旨が書かれています。

コントロールと通知: コスト管理を導入する際の一般的な最初のステップは、ポリシー外のコストまたは使用量イベントが発生した場合に通知するように設定することです。

目次

設定手順

今回はAWSマネジメントコンソールを使った設定方法を解説します。

1. AWS Budgetsの画面で予算を作成

検索欄にbudgetsなどを入力して、AWS Budgetsの画面を開きます。

マネジメントコンソールでbudgetsを入力

AWS Budgetsの画面が開いたら、予算を作成ボタンを押します。

予算を作成ボタンを押す

2. コスト予算の選択

コスト予算を選択し、予算を設定ボタンを押します。

コスト予算を選択し、予算を設定ボタンを押す

3. 予算を設定

まず、予算名と期間を設定します。

予算名と期間を設定

  • 名前 : 予算に付ける名前です。ここで付けた名前がメールの件名や本文に含まれることになります。
  • 間隔 : 月別を選択します。
  • Budgets effective dates : 定期予算を選択します。
  • 開始月 : 今月を設定します。

次に、毎月の予算を指定します。

固定10ドルを入力

固定を選択し、予算額は適当な値を入力してください。

ここでは10ドルとしておきます。

以下の追加の予算パラメータでは、予測請求額の計算に含めるAWSのサービスの種類やリージョンなどを絞ることができますが、今回はAWSアカウント全体での予測請求額で通知をしたいので、デフォルトのままとします。

追加の予算パラメータはデフォルトのまま

ここまで来たら、画面右下のしきい値を設定するボタンを押します。

しきい値を設定するボタンを押す

4. しきい値と通知先を設定する

続いて、しきい値を設定します。

予測コストを選択し、しきい値を100%に設定

予測コストを選択し、アラートのしきい値を100%とします。

こうすることで、月末の予測請求額が予算額100%(ここでは10ドル)を超過する見込みであると通知されるようになります。

さらに通知の宛先とするメールアドレスを入力します。

メールアドレスを入力

最後に予算の確認ボタンを押し、次画面で確認ボタンを押せば設定完了です。

終わりに

これで月の請求額が10ドルを超える見込みになると、月の途中でも通知メールが届くようになりました。

なお、AWS BudgetsではAWS Chatbotと連携してSlackに通知することも可能ですが、メール通知よりも少し設定手順が多いので本記事では割愛します。

Slackに通知してみたい方は以下の記事を参考にしてください。

Web系エンジニア2年目による1年間の振り返り

はじめに

昨年2020年の1年間は、私がWeb系のエンジニアになって9ヶ月目〜1年8ヶ月目にあたります。

おおよそエンジニア2年目にあたるこの期間を振り返るとともに、2021年の抱負について考えたいと思います。

目次

本業

本業では引き続きSREチームに所属し、CI/CDの整備やAWSでのインフラ構築・管理などを行いました。

様々なタスクをこなしましたが、2年目として特に印象に残ったのが以下の2案件です。

  1. 既存サービスのインフラ刷新
  2. Go + Lambda + SQSのマイクロサービス新規構築

既存サービスのインフラ刷新

3年以上運営されている既存サービスのインフラ保守を、新たに私が所属するSREチームで引き取ることになりました。

この既存サービスのインフラは、SREが管理する他のインフラと比較して設計的に劣後する箇所が見受けられ、またデプロイが手動であるなど、いくつかの課題を抱えていました。

そこで既存のインフラのままで保守しつつ、並行して4ヶ月かけて新規インフラを構築し、既存から新規へ移行させました。

詳細は伏せますが、主に以下の改善を行いました。

  • セキュリティの向上
  • Terraformの導入
  • デプロイの自動化

移行は無事完了し、現在は新インフラが問題無く稼働しています。

この案件の推進に関しては私がリーダーとして一任され、チームのもう1人のメンバーと二人三脚で進めました。

私はプレイングマネージャー的にプロジェクト管理をしつつ、自らも手を動かしてインフラ構築を行いました。

もう1人のメンバーと相互に補完し合って案件を推進することができ、インフラ系のチーム開発として非常に良い経験を得ることができました。

Go + Lambda + SQSのマイクロサービス新規構築

とあるWebサービスに機能追加が必要となり、検討した結果、Lambdaでマイクロサービスを構築することにしました。

Lambda上で動くGoのコードもSREで書きました。

実務でGoを書くのはこれが初めてで苦労も多かったですが、非常に勉強になりました。

Goは引き続き書いていきたいと思います。

社外活動

JAWS-UG(Japan AWS User Group)というAWSのユーザーグループがあります。

JAWS-UGには目的・地域別に分かれた50以上の支部が存在するのですが、私はその中でAWS初心者向けに特化した「初心者支部」に運営メンバーとして参加しています。

2020年には10回以上のオンラインイベントを開催し、その規模も毎回参加者100人以上となっています。

こうした各イベントにおいて、私は5人以上いる運営メンバーと役割分担をしながら、時には司会進行をしたり、時にはハンズオンイベントの講師サポート(参加者からの質問対応など)をしたりしました。

登壇

前述のJAWS-UGのオンラインイベントで、計2回登壇しました。

JAWS SONIC 2020

1つ目はJAWS SONIC 2020という24時間イベントです。

登壇テーマは、AWSがクラウドアーキテクチャのベストプラクティスとして文書で公開しているAWS Well-Achitectedとしました。

非常に深いテーマですが、初心者支部代表として、初心者にもわかりやすい・親しみやすい内容となるよう心掛けました。

youtu.be

JAWS-UG 初心者支部 & 大分支部

2つ目はJAWS-UG初心者支部と大分支部でのコラボ開催となったAWS Amplifyをテーマとした勉強会です。

実務では全く触ったことのないAmplifyでしたが、先に登壇を宣言し、そこから発表当日までに内容を勉強し資料を作るという締め切り駆動型で臨みました。

プレッシャーはありましたが、未知のAWSサービスに触れることで、技術の幅が広がりました。

技術記事投稿

技術記事をQiitaでは14本、Zennでは5本投稿しました。

Qiitaではデイリートレンド入りすることが3回ほどありましたが、いずれも小ネタで、はてなブックマークなどで話題となるような技術記事までは書くことができませんでした。

2021年はより気合の入った記事を書いて、そうした話題になれたらと思います。

執筆活動

書籍ではありませんが、Techpitというプログラミング学習プラットフォームで、テキストベースの教材を3本執筆、公開しました。

それぞれ字数にすると50万字程度はあるので、技術書一冊(200〜300ページ)ほどのボリュームになるかと思います。

そのため、執筆には本業の合間を縫って、かなりの時間をかけました。

そうした苦労の甲斐もあってか、多くの人に手に取ってもらえ、またサイトでのレビューでも平均4.7点〜5.0点(5点満点評価)と高い評価をいただくことができました。

その他、執筆に際してはできるだけ正確な解説となるよう公式のドキュメントを読み込むなど私自身も非常に勉強になりましたので、アウトプットのひとつのかたちとして取り組んで良かったと思います。

Twitter

フォロワー数は年初に2,400人だったところ、4,200人まで増えました。

1,800人の増となります。

Twitterを通じてリアルで知り合えた人も増えたので、今後も地道に続けていきたいと思います。

2021年の抱負と最後に

2021年の抱負としては、これまでのような活動を続けつつ、本業であるSREに関して、より専門的で高度な知見・スキルを身に付け、更にプロダクトに貢献できる人材になりたいと考えています。

そのために思い切ったこともしようと計画もしていますが、その詳細はまた別の機会に・・・(以下、後日に追記しました)。

では、本年もどうぞよろしくお願い致します。

Laravel + CircleCI + AWSでCI/CDを学ぶチュートリアルを公開しました

はじめに

Laravel + Vue.jsのサンプルアプリケーションをCircleCIを使ってAWS(EC2)にデプロイする、CI/CDパイプライン構築を学ぶチュートリアルをTechpitで公開しました。

このチュートリアルはどんな人に向いているか

以下のようなプログラミング学習者をターゲットとしています。

  • Herokuにデプロイはできるけれど、AWSへのデプロイはまだという方
  • AWSへ手動でデプロイはできるけれど、自動デプロイさせる方法がわからないという方

既にエンジニアとして実務に付いている方でも「職場にCI/CD環境はあって利用はしているけれど自分自身でゼロから構築したことは無い」という方であれば、効率的に学べる内容になっているのではと思います。

このチュートリアルを終えることで身に付く知識

チュートリアルでは以下について段階的に学べる構成となっています。

  • CircleCIの基本的な使い方(そもそもの構文やキャッシュの使い方など)

  • Laravelでのテストの書き方の初歩的な知識

  • EC2 + RDSでLaravel + Vue.jsアプリケーションを動かすための環境構築方法(nginx, PHP-FPMの設定方法など)

  • CircleCIからEC2にSSHログインしてデプロイさせるための方法(SSHキーの取り扱いなど)

  • AWSのデプロイサービスであるCodeDeployを使ったデプロイ方法とその結果をSlack通知する方法

  • AWSのCI/CD関連サービスであるCodePipeline/CodeBuild/CodeDeployを組み合わせてデプロイする方法

書いた人

昨年の9月からSREチームに配属になって色々なタスクを経験したのですが、その中で「とあるレガシーなアプリケーションをEC2に自動デプロイさせるためのCI/CDパイプラインを構築する」というものがありました。

職場の主要なアプリケーションはCI/CDが整備されていますが、そのレガシーアプリケーションは未だに手動デプロイだったのです。

そこでCircleCIやCodeDeployなどに触れ、得られた知識を元に今回のチュートリアルを書きました。

終わりに

4月の頭から執筆を始め、時々Twitterで途中経過報告をしたのですが結構反響が大きかったです。

AWSやクラスメソッドの方にいいね・リツイートされたり・・・。

だからといって、その方々がこのチュートリアルをオススメしているわけでは決してありませんが(当然中身は知らないわけだし)、執筆と終わりの見えないスクショ作業を続ける上で大変励みになりました。

CI/CDの構築方法を学びたい、という方はぜひ手に取ってもらえればと思います。

全7章構成ですが、0章から1章の途中ぐらいまでは無料で公開されています。気に入った方はその続きもぜひ。

【GitHub Actions】S3にキャッシュするアクションをリリースしました

GitHub Action - actions-s3-cache

はじめに

GitHub Actionsで、キャッシュをS3に保存するアクションactions-s3-cacheをリリースしました。

github.com

GitHub ActionsにおいてCI/CDを行う際にパッケージインストールやビルドを実行する場面があるかと思いますが、それらの結果をキャッシュするためのアクションとなります。

目次

公式のキャッシュ機能との比較

安定性

GitHub Actions公式のキャッシュ機能actions/cacheは、現在以下の問題を抱えているようです。

  • Pull Requestでコケた時にRe-run jobsするとactions/cacheアクションが正常に動作しない
  • actions/cacheアクションは時折キャッシュの取得に失敗することがある

GitHub Actionsの知見ご紹介 - Masteries

この点に関して、今回公開したアクションは安定しているのではと思います。

ジョブ異常終了時の挙動

公式のキャッシュは以下の仕様となっています。

  • 使用するステップを記述すると、そこがキャッシュをリストアするステップとなるが、キャッシュの保存に関しては、actions/cacheのステップが存在するジョブの最後にPost + actions/cacheというステップ名で実行される
  • ジョブが正常終了しなかった場合は、キャッシュを保存するステップは実行されない

つまり、

# 略
    steps:
      # 略
      - name: cache composer
        uses: actions/cache@v1.1.2
        with:
          path: vendor
          key: composer-v1-${{ hashFiles('composer.lock') }}
      - run: composer install -n –prefer-dist
      - run: vendor/bin/phpunit # テスト

のように、1ジョブ内で

  1. 公式のキャッシュを使用
  2. パッケージのインストール
  3. テストの実行

を実行する場合、初回のテストが通るまでインストールしたパッケージがキャッシュされることはありません。

actions-s3-cacheでは、後続のステップでエラーが発生してジョブが異常終了した時でも、キャッシュの保存を行います。

  • キャッシュを探す
  • 無ければパッケージをインストールする or ビルドする
  • キャッシュを保存する

という一連の流れを、アクション使用の1ステップ内で実行しているためです。

キャッシュヒット率

公式のキャッシュはGitHubリポジトリごとにキャッシュの保存容量が5GBあるそうです。

しかし、実際に使っていると5GBをまだ超過していなさそうなのに、キャッシュミスが発生するケースが見受けられました。

私の職場のとあるリポジトリについて、AさんがActionsでテストをしてキャッシュが保存された後、同じに日にBさんがテストをしたら、キャッシュのキーは同じなのにキャッシュミスになることがありました。

actions-s3-cacheではキャッシュのキーが合えば確実にキャッシュヒットする、はずです。

複数のディレクトリ・ファイルのキャッシュ可否

公式のキャッシュは、キャッシュ対象としてひとつのディレクトリしか指定できません。

また、ファイル名を指定してキャッシュすることができません。

利用シーンは限られるかもしれませんが、actions-s3-cacheでは複数のディレクトリとファイルの組み合わせをまとめてキャッシュ可能です。

使い方

例として、以下のように記述するとnpm ciによって作成されたnode_modulesをS3にキャッシュし、次回以降はS3からリストアします。

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: shonansurvivors/actions-s3-cache@v1.0.1
        env:
          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          AWS_DEFAULT_REGION: ap-northeast-1
        with:
          s3-bucket: your-s3-bucket-name # 必須
          cache-key: npm-v1-${{ hashFiles('laravel/package-lock.json') }} # 必須 ('.zip' は記述不要)
          paths: node_modules # 必須(キャッシュするディレクトリやファイル。複数ある場合はスペース区切りで記述) 
          command: npm ci # 必須(インストールやビルドのコマンドを記述)
          zip-option: -ryq # 任意 (デフォルト: -ryq)
          unzip-option: -n # 任意 (デフォルト: -n)
          working-directory: laravel # 任意 (デフォルト: ./)

事前準備としては、

  • S3バケットを作成する
  • S3バケットを読み書き可能なポリシーを持ったIAMユーザーを作成する
  • GitHubリポジトリのsettings画面で上記IAMユーザーのアクセスキーIDとのキーをsecretsに設定する

が必要となります。キャッシュですので、S3バケットにはライフサイクルポリシーを付けて一定日数でオブジェクトが削除されるようにすると良いかと思います。

以下はIAMのポリシーの例です。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:GetObject",
                "s3:ListBucket",
            ],
            "Resource": [
                "arn:aws:s3:::your-s3-bucket-name",
                "arn:aws:s3:::your-s3-bucket-name/*"
            ]
        }
    ]
}

なお、アクションの種類には、DockerアクションとJavaScriptアクションが存在しますが、actions-s3-cacheは後者のJavaScriptアクションです。

ですので、GitHubが提供するVM環境で直接実行されます。

最後に

職場では今回のアクションの原型となる、S3キャッシュのためのシェルを作って使っているのですが、GitHubリポジトリごとにシェルをコピペしなければなりませんでした。

今回アクションとしてOSS化したことで共通的に使い回せるようになりました。

この記事を読んでいただいた方にも、このアクションを使っていただけたら幸いです。