クラウドとフロントエンドの未来を考えるBlog

University of London BSc Computer Science 1年目の指南書

Sun, 01 Oct 2023 22:00:00 GMT

UoL(University Of London) の BSc Computer Science に入学して 1 年が経ちました。 1 年目は UoL のシステムに慣れることが本筋の学習と同じくらい大事だったりします。周りを見ていると、だいたいみなさん同じところでつまづいているように思えたので、1 年目の指南書を書いてみました。

なお、入学までに取り組んだ内容についてはこちらにまとめています。

Disclaimer

この記事はあくまで個人の経験に基づいたものです。公式の情報は UoL が提供している情報を参照してください。
本記事は PBA(Performance Based Admission)入学者を対象に書いています。Standard Entry で入学できた方は一部、参考にならない部分があるかもしれません。PBA と Standard Entry の違いについては前回の記事にまとめているので、そちらを参照してください。

UoL でのモジュールの進め方

UoL での学習はモジュールという単位で履修が可能です。モジュールは履修科目にあたります。一つのモジュールは 22 週間で構成されており、4 月 ~ 9 月、10 月 ~ 3 月の半年間(1 セメスター)をかけて受講します。これらのモジュールはすべてCourseraプラットフォーム上で受講することになります。卒業には 22 モジュールと Final Project(卒業研究)の合格が必要です。

モジュールの評価は主に以下の 3 つの要素で構成されています。(モジュールごとに比重は異なります)

Coursera 上で行われる Assignment
Mid-term Assignment
Final Exam

1 は Coursera 上で行われるミニテストのようなものです。モジュールにもよりますが、だいたい 2weeks 毎にテストが行われます。テストは複数回受けることができますが、締切を過ぎると受けることができなくなるので注意が必要です。モジュールにもよりますが評価全体に対する比重はそこまで大きくないです。

2 はセメスターの中間で行われる課題です。レポート形式の課題が出されることが多いです。評価全体に対する比重は大体 20%~50%で、提出期限はおおよそ 1 ヶ月です。推奨される時間は 20 時間程度ですが、課題の内容によってはそれ以上かかることもあります。

3 は多くのモジュールで最も比重が高いです。Final Exam は専用のアセスメントツールを用いてオンライン上で行われます。

モジュールの合格には Mid-term と Final Exam の加重平均が 40%を超える必要があります。また、Mid-term Assignment と Final Exam の両方で 35 点の足切り点が設けられています。

1 セメスターで履修するモジュールは 4 つまでです。1 年間で最大 8 つのモジュールを履修することになります。

入学から受講開始までの流れ

オリエンテーションを受ける

入学が決定すると、セメスターが開始される前に、Coursera 上でオリエンテーションを受講します。このオリエンテーションで UoL の基本的な事項について学びます。4~6 時間くらいで完走できます。

受講登録を行う

入学を許可されると専用の学生ポータルのアカウントが発行されます。このポータルサイトから履修登録(モジュールの登録)と学費の支払いを行います。学費はモジュールごとの支払いになります。モジュールの登録を行わない場合、学費は発生しません。

慣れるまでこのポータルサイトの使い方に戸惑うことが多いので、早めに登録を済ませておくと良いです。なお、モジュール開始後も 14 日以内であればモジュールのキャンセルが可能です。本業との兼ね合いでどうしても履修登録をキャンセルしたい場合は、この期間内にキャンセルを行うようにしましょう。

PBA で入学した場合、はじめのセメスターでは 2 科目しか履修することができません。「Introduction to Programming I」と「Discrete Mathematics」or「Computional Mathematics」を選択します。この 2 科目の履修登録を行うこと & Mid-term Assignment でそれぞれ 50 点以上を獲得することが次の科目を履修できる条件になります。この条件は必ず満たすようにしましょう。

注意点 / Tips

RPL(Recognition of Prior Learning)を最大限活用する

UoL には RPL と呼ばれる事前学習プログラムが存在します。これは、他の大学で取得した単位や、UoL 指定の Certificate を UoL の単位として移管することができるプログラムです。RPL にはいくつかのメリットがあります

1 セメスター 4 モジュールの制限外であるため、通常のペースより早く単位を取得できる
モジュールの費用がかからないため学費を安く抑えることができる
Mid-term Assignment, Final Exam が免除されるため、単位取得にかける時間が減る

2023.10 現在で BSc Computer Science では以下の科目が RPL に対応しています。
Google IT Support Professional Certificate
IBM Data Science Professional Certificate
IBM AI Engineering Professional Certificate

Google IT Support Professional Certificate は 1 年次に受講する「How Computer Work」の受講が免除されます。PBA の場合、はじめのセメスターで 2 科目しか履修できないため、合わせてこのプログラムを受講することをおすすめします。

IBM Data Science Professional Certificate、IBM AI Engineering Professional Certificate は 3 年次に受講する「Machine learning and neural networks」と「Data science」が免除されます。ただし、3 年次に選択するコースによっては、卒業要件にこの 2 科目が含まれていない場合があるため注意が必要です。3 年次に「Data Science コース」、もしくは「Machine Learning コース」を選択する場合は上記 2 科目を RPL として適用することができます。

詳細はこちらを参照してください。

Progression Rule を理解する

見落とされがちですがとても重要なルールです。学生はすべてのモジュールを自由に選択できるわけではなく、受講できるモジュールにはある程度の制限があります。これを Progression Rule と呼びます。このルールを理解するにはいくつかの前提を抑える必要があります。

BSc Computer Science は 22 モジュールと卒業研究に合格することで卒業が可能です。この 22 モジュールは以下のようにレベル分けされています。

Level4: 8 modules
Level5: 8 modules
Level6: 6 modules
Final Project

また、前述した通り、RPL を活用することで、Level4 に属するモジュールを 1 つ(How Computer Work)、Level6 に属するモジュールを 2 つ(Machine learning and neural networks, Data Science)免除することができます。

Progression Rule では以下の事項が定められています。以下に特に重要なルールを抜粋します。

PBA 入学の場合、初めのセメスターでは Level4 にあたる「Introduction Programming I」と「Discrete Mathematics」or 「Computional Mathematics」のどちらかを履修する必要がある。PBA で入学した学生が、他の Level4 の科目を履修するには、この 2 科目を履修登録すること & Mid-term Assignment でそれぞれ 50 点以上を取得する必要がある。(前述した通り)
正式な学生として認められるには、「Introduction Programming I」と「Discrete Mathematics」「Computional Mathematics」の 3 科目に合格する必要がある。
Level5 の科目を受講するには、PBA の最初のセメスターで登録した科目への合格と「Introduction Programming II」の科目を受講登録する必要がある。
Level6 の科目を受講するには、Level5 の科目を 3 科目以上合格している必要があり、かつ「Software Design and Development」「Object Oriented Programming」のうちのどちらかに合格している必要がある
Final Project に参加するには、Level5 の科目の全てに合格している必要がある

また、もう一つ理解すべき重要な事項として、前セメスターの合否が確定するのは次のセメスターの履修登録後になる点があります。例えば、ルール 4 の「Level6 の科目を受講するには、Level5 の科目を 3 科目以上合格している必要がある」の条件を満たすためには、Level6 の受講を開始する 2 つ前のセメスターで Level5 の科目を 3 科目以上受講している必要があります。これは、次のセメスターの履修登録の段階で前セメスターで受験した Final Exam の結果がまだ確定していないためです。このルールは万が一単位を落としてしまった場合(再履修が必要になった場合)にも大きく影響します。

例えば、2023.4~2023.9 月に履修した科目が不合格になった場合、その結果が確定されるのは 2023.10 の履修登録が終わった後なので、この科目を再履修するには、2024.4 のセメスター開始を待つ必要があります。次の Level への進級条件となっている科目が不合格になった場合、卒業までに 1 年間の遅れが生じることになります。

どの順番でモジュールを履修するか

Progression Rule により進級の条件が細かく定められているため、最短で卒業するための順番はほぼ固定されます。最短卒業を目指さない場合でも、進級条件になっている科目(*)は優先的に取るようにしましょう。以下、最短で卒業するための履修順序の例です。※ Machine Learning コースを選択した場合

1st セメスター:

Introduction Programming I (Level4) ※
Discrete Mathematics (Level4) ※
Google IT Support Professional Certificate (RPL)

2nd セメスター:

Introduction to Programming II (Level4) ※
Computational Mathematics (Level4)
Fundamentals of Computer Science (Level4)
Algorithms and Data Structures I (Level4) ※

3rd セメスター:

Web Development (Level4)
Object Oriented Programming (Level5) ※
Algorithms and Data Structures II (Level5)
Graphics Programming (Level5)

4th セメスター:

Software Design and Development (Level5) ※
Databases, Networks and the Web (Level5)
Programming with Data (Level5)
Computer Security (Level5)
IBM Data Science Professional Certificate (RPL)
IBM AI Engineering Professional Certificate (RPL)

5th セメスター:

Agile Software Projects (Level5)
Databases and advanced data techniques (Level6)
Artificial intelligence (Level6)
Natural language processing (Level6)

6th セメスター:

Intelligent signal processing (Level6)
(このタイミングでは Level5 の科目全ての合格が確定していないため、Final Project に参加することはできない)

7th セメスター:

Final Project

PBA で入学した場合、最短でも卒業に 3.5 年かかる

Standard Entry の場合最短で 3 年での卒業が可能ですが、PBA 入学の場合 7th セメスター(3.5 年)を必要とします。

その他、個人的なアドバイス

難易度をばらつかせる

難易度の高いモジュールを一つのセメスターに詰め込むと、そのセメスターが非常に辛くなります。非公式ではありますが、各モジュールの難易度表が有志により公開されています。この難易度表は自分の肌感とも合致しているので、参考にしてみてください。また、モジュールによっては特定のプログラミング言語が指定されている場合があります。1 つのセメスターで異なるプログラミング言語を学ぶことは学習コストが高くなるため、なるべく同じプログラミング言語のモジュールを同じセメスターに詰め込むようにしましょう。(大学側も同じセメスターに同じプログラミング言語のモジュールを履修することを推奨しています)

※ 先ほどの履修順序の例では、可能な限り難易度が平準化されるようにしています。

モジュール開始前に過去問に目を通す

各モジュールの過去問はGithub上に公開されています。過去問を活用することで各モジュールの最終到達点のイメージが明確になるので、モジュールの開始時から参考することをお勧めします。

日本語の文献にも目を通す(英語苦手な人向け)

Final Exam は英語で行われるため、最終的には英語で学んだことを英語でアウトプットできる必要があります。ただし、私のように英語が苦手な人は先にある程度日本語でインプットしておいた方が英語での理解力が上がると思います。

以下、私が参考にした日本語の文献です。(Level4)

マグロウヒル大学演習離散数学(改訂 2 版): コンピュータサイエンスの基礎数学 Discrete Mathematics, Computational Mathematics, Fundamentals of Computer Science は大体この本一冊でカバーできます。離散数学の本はいくつか手を出しましたが、この本が一番良かったです。

計算理論の基礎 [原著第 3 版] 1.オートマトンと言語
 計算理論の基礎 [原著第 3 版] 2.計算可能性の理論 Fundamentals of Computer Science の主要テーマである「オートマトン」「チューリングマシン」の領域を上記の書籍より広くカバーしています。モジュールの内容より幾分か発展的な内容ではありますが、より理解が深まるのでお勧めです。

学ぶ深さに濃淡をつける(すでにエンジニアのキャリアがある人向け)

すでに IT エンジニアとしてのキャリアがある人にとっては、Introduction Programming や Algorithm and Data Structure などのモジュールは少々物足りないかもしれません。すでに十分な知識がある分野については、1 ヶ月くらいですべてのカリキュラムを終えてしまって、他のモジュールに時間を割く方が良いかもしれません。自分の場合、Introduction ProgrammingI,II や Algorithm and Data Structure, Computional Mathematics に関しては特に新しく学ぶことはなく、退屈を通り越してイライラすることが多かったです。。一方で、Discrete Mathematics, Fundamentals of Computer Science は非常に興味深く、新しく学ぶ概念も多かったためこちらを重点的に学習しました。

Final Exam に使用されるツールに慣れる

Final Exam は自宅で受験することができます。この試験には UoL から提供される専用のツールを使用します。

このツールは試験中に画面共有、Web カメラ、マイクによる監視を行います。また、試験中には他のアプリケーションを起動することができません。カンニングや、許可されていない電子デバイスの使用、その他不正と疑われる動きが検知されると不正行為として Flag が立てられます。(Flag を建てられると即アウトではなく、実際に不正が行われたかどうかは後から人間の目によって確認されます) 試験は 4 時間と長時間になるため、トイレ休憩や飲食は許可されています。

試験開始の 1 ヶ月前にはこのツールを使用した Mock Test を受けることができるので、試験開始前にこのツールに慣れておくと良いです。 ※ 2023.10 時点での情報です。今後変更される可能性があります。

Q&A

Q. 働きながらでもやっていける？

A. 最短卒業を目指すのであればそれなりに大変。過去問をうまく活用する等効率よく学習することが重要になると思う。すでにエンジニアとしてのキャリアがある人は、少なくとも Level4 はそこまで大変ではないかもしれない。(数学は別)

Q. 英語が苦手でもやっていける？

A. 講義動画には英語のスクリプトが付いているので、最悪 DeepL に突っ込めば日本語でも読めるのでなんとでもなる。ただし、Final Exam は Translater を使えないので、最終的には英語で学んだことを英語でアウトプットできる必要がある。たまに問題文の英語が理解できないことがあった。導入過程を英語で説明しないといけない問題も出るので、そういった問題に対してはいくつか自分の中での定型文を作っておくと良い。

他のメンバーと一緒に協力して作品を作るモジュールもあるので、そういった場合は英語でコミュニケーションを取る必要がある。

Team Project があるモジュール

Web Development (Level4)
Agile Software Projects (Level5)

※ 特に Agile Software Projects は口頭ベースの議論が多く日本人は苦労するようだ・・

Q. 学費はどれくらいかかる？

A.2023.10 に 4 モジュール履修した時は、634,700 円だった。卒業までに 350 万円くらいかかると思う。円安辛い・・

Q. 週何時間くらい勉強してる？

A.モジュール、人による。講義を聞くだけなら 1 モジュールあたり 2 時間/週くらい。加えて、Mid-term Assignment は 10~15 時間くらい。Final Exam は 1 モジュールあたり 20 時間くらいだった。おそらく Level5 になるともっと時間がかかると思う。

Q. 楽しい？

A.楽しい。自分は次のセメスターから Level5 の科目を履修できるので楽しみ。

Q. 大学に入って感じたデメリットは？

A. 英語や、業務に関係する勉強の時間が取りにくくなった。何をしてても頭の片隅に常に締め切りがちらつく。円安で学費が辛い。

まとめ

大体みなさん同じようなところでつまづいているように思えたので、1 年目の指南書を書いてみました。この記事が少しでも参考になれば幸いです。

何か質問があれば Twitter 等で DM いただければお手伝いできると思います。もし本記事の内容で間違いがあれば、ご連絡いただけると助かります。 > UoL 在籍のみなさん

働きながらUniversity of Londonでコンピュータサイエンスを学ぶ

Mon, 03 Oct 2022 22:00:00 GMT

10 月から University of London の Bachelor of Science in Computer Science programme にオンラインで入学することになりました。目指した経緯と入学までにやったことを書き綴っています。

思いつきで書き殴った文章なので有意義なことは書いていません。

~~2023.10 追記~~ 入学から 1 年が経過したので、以下の記事を追加しました。 University of London BSc Computer Science 1 年目の指南書

なぜコンピューターサイエンスを学ぼうと思ったか

流行のフレームワークやライブラリを追っかけるようなことばかりやっていて本質的な技術力が伸びていないように感じたから
ある程度実務経験を積んだ上で改めて CS を体系的に学ぶことでエンジニアの自力を伸ばせると期待しているから
単純にやってみたかったから

なぜ修士ではなく学士？

自分の場合は研究よりも CS を体系的に学んでみたいというモチベーションが強かったので修士ではなく学士を選択しました。

一応、修士入学の可能性も考慮して研究計画を作ってみたりもしたのですが特に研究したいテーマも無かったので薄っぺらい内容しか書けませんでした。(やるとしても Bachelar 取ってから)

なぜ University of London を選んだか

大学は以下の観点で選びました。

CS コースがあること
完全オンラインで履修できること
どうせやるなら英語で学びたかった

加えてイギリスの大学は 1 年目から専門科目を学ぶことができて最短で 3 年で卒業できることから最終的に UoL を選択しました。

もう一つの候補としてアメリカの University of the People がありました。こちらは卒業まで最短でも 4 年かかること、専門科目以外の科目も履修する必要があることから University of the People は選択しませんでした。

余談ですが、この University Of the People は UoL と比較して学費が圧倒的に安いのが特徴です。元々は貧困国の人たちにも高等教育を提供する目的で提供されているカリキュラムなので、ほぼ無償に近い金額で CS の学士を取得することができます。また、英語力が requirement に達していない場合でも、9 週間の語学カリキュラムを受講して Final Exam をパスすることで入学が許可されます。日本ではほとんど知名度がありませんが、経済的な理由で大学に進学できない人やエンジニアに Job チェンジしたい人たちにとって有力な選択肢になり得ると思いました。

出願までにやったこと

英語
必要書類の準備

英語

自分の場合、英語の requirement を突破するための準備が 99%を占めていました。 University of the People と異なり UoL の入学には英語力の証明が必要となるので、英語に自信がない人はある程度準備が必要になります。

とはいえ、Master コースと比較すると求められる基準はそこまで高くないので地道に準備をすれば達成可能なレベルだと思います。

English requirements
*2022.10 時点で TOEFL:87, IELTS: overall 6, with 5.5 in each sub-test

イギリスの大学だからなのか TOEFL より IELTS の方が明らかに基準が低いように思えたので IELTS に絞って対策を行いました。

必要書類の準備

出願にあたっては身分証明書、英語の卒業証明書、CV(英文履歴書)、志望動機、英語力の証明書などが必要になります。

身分証明書: パスポート等

志望動機: 250words でよかったのでサクッと書いてネイティブチェックだけ通しました。正直そんなに重要視されてないように思います。

英語の卒業証明書: 英語の卒業証明書を発行してくれない場合は専門の翻訳業者に依頼する必要があります。その場合、成績証明書の取り寄せから翻訳完了まで 2 週間以上かかる可能性があるので卒業証明書に関しては特に早めに準備しておいた方が良いです。

英文履歴書: いわゆる CV というやつです。ネットには CV のテンプレートや書き方のノウハウが転がっていますが、個人的には下手に自分で書くよりお金払って専門の業者にお願いした方が良いです。

大体 1 万円~2 万円くらい払えばかなり良いクオリティで仕上げてくれます。後述する Performance Based 選考の場合 CV は重要な選考資料になるため、よほど CV を書くのに慣れている、もしくは過去に作成したものがあるといった方以外はプロにお任せしましょう。(日本語の履歴書は自分で書く必要があります)

選考基準について

いわゆる学力試験や面接みたいなものはありません。2022.10 現在、以下の 2 種類の採点基準があります。

Standard Entry: 過去に卒業した成績証明書の成績から判断
Performance Based: IT 業界における過去の職務実績で判断

どちらかの採点基準で合格をもらえれば晴れて入学が許可されます。自分の場合は Standard Entry では不合格でしたが Performance Based で合格することができました。過去の成績(特に数学)に自信がない方は CV に自分の実績を証明できる根拠をしっかり書き込みましょう。自分の場合は過去に執筆した書籍や、AWS 時代のパブリックスピーキングの Youtube リンクなどを記載しました。

なお、Standard Entry で不合格になった場合は、初年度取得できる単位数が制限されてしまうため可能な限り Standard Entry で合格した方が良いです。(カリキュラムに関しては今後変更があるかもしれません)

実際働きながらやっていけるの？

まだカリキュラムが始まっていなのでなんとも言えません。フルで単位を取得しようとした場合、推奨学習時間が 28h/week となっているのでかなりタフであることは間違いなさそうです。当然授業は全て英語で行われるので、英語が苦手な人は 1~2 割増しくらいの時間を覚悟した方が良さそうです。

[祝GA!] Aurora Serverless v2 の特徴まとめ

Sun, 24 Apr 2022 03:48:03 GMT

2022.4.22 に Aurora Serverless v2 が GA された。以前から気になっていた機能なので特徴について気になった点をまとめてみた。

Disclaimer

2022.4.22 時点での情報です。最新の情報は公式ドキュメントを参照してください。
本記事では網羅性はあまり意識していません。繰り返しになりますが、詳細は公式ドキュメントを参照してください。

Aurora Serverless v2 の主な機能概要

負荷に応じてインスタンスタイプが自動的にスケールアップ
Provisioned インスタンスと Serverless インスタンスを混在して一つのクラスタに配置できる
v1 と比較してよりきめ細やかな Option が指定可能(インスタンスタイプ、Global Database の指定等)

※ Disclaimer でも触れた通り網羅性は意識していません

1. 負荷に応じてインスタンスタイプが自動的にスケールアップ

0.5 ACU 刻みで MIN ,MAX キャパシティの指定が可能
スケールアップ/ダウン時のユーザ影響なし
インスタンスの入れ替わりが起こるのではなく、実際に稼働しているインスタンスがトランザクションを受け付けながらスケールアップが行われる(in place scaling)
- 新しくインスタンスが追加されるわけではないため、キャッシュがウォーミングされていないといった状態を回避しやすい
スケールアップのスピード(scaling rate)はそのタイミングの ACU に依存する。大きい ACU であればあるほどジャンプできる ACU 数が増える
Buffer Pool などのパラメータも動的に変更してくれる
- mysql の max_connection は MAX で設定される ACU の max_connection が設定される

Aurora のアーキテクチャの特徴として、コンピュート層とストレージ層が分離されているためこういったスケール戦略が可能らしい ↓

architecture.png

2. Provisioned インスタンスと Serverless インスタンスを混在して一つのクラスタに配置できる

v2 への移行には新たにクラスタを起動する必要はなく、既存のクラスタに Serverless v2 インスタンスを混在することができる
- ※ ただし Aurora の version は serverless v2 が対応しているものを使用する必要がある
段階的な移行の手段として、v2 インスタンを徐々に増やしていくといった方式が可能
Custom endpoint の機能を用いて特定の Reader endpoint にだけ Serverless v2 を割り当てるといった運用も可能

3. v1 と比較してよりきめ細やかな Option が指定可能(インスタンスタイプ、Global Database の指定等)

v1 と異なり Read Replica や Global Database にも対応
v1 では ACU のスケールは 2 倍ずつしか設定できなかったが、v2 ではきめ細かい ACU サイズが指定可能
Global Database 内の設定でも Provisioned と Serverless を混在させることが可能
- フェールオーバー先のリージョンに Serverless インスタンスを配置することで、トータルのコストを抑えることができる

Aurora Serverless v2 の使い所

トラフィックが予想できないようなユースケース
特定の時間帯のみ起動するアプリケーション
Writer だけ、もしくは Reader だけ動的にスケールアップ/ダウンさせたい場合
- 分析用クエリだけは Aurora Serverless v2 を使用する等
逆に安定してトラフィックが予想できる場合は Provisioned インスタンスを用いる

refer to: Aurora Serverless v2 use cases

Aurora Serverless v2 使用時の注意点

対応 version が限られている

MySQL
- Aurora MySQL 3.03.0 or higher
- MySQL 8.0
PostgreSQL
- Aurora PostgreSQL 13.6.0 以上
- PostgreSQL 13

refer to: Upgrade paths for MySQL-compatible clusters to use Aurora Serverless v2

ユーザ利用領域以外の ACU も考慮が必要

0.5ACU から設定可能だが Engine や Tools が使用する ACU についても考慮する必要あり
例えば Performance Insights を使用した場合最低でも 2ACU 使用されるため、ACU の minimum はそれよりいくつか大きいサイズを指定する必要がある

refer to: Choosing the minimum Aurora Serverless v2 capacity setting for a cluster

Aurora serverless v1 と v2 との比較(一部抜粋)

詳しくは以下リンクを参照

refer to: Comparison of Aurora Serverless v2 and Aurora Serverless v1

Feature	Aurora serverless v2	Aurora serverless v1
最小 ACU(MySQL)	0.5	停止状態: 0 起動状態: 1
最小 ACU(PostgreSQL)	0.5	停止状態: 0 起動状態: 1
最大 ACU(MySQL)	128	256
最大 ACU(PostgreSQL)	128	384
フェールオーバー	Yes	Best effort
グローバルデータベース	Yes	No
クラスタの停止	手動停止が必要	自動で停止するオプションも可能
バッファキャッシュ	動的にバッファサイズが変化	サイズ変更後にキャッシュの rewarm が発生してしまう
価格(ACU Hour ・Tokyo resion)	$0.2	$0.1
Data API	非対応 😢	対応
Query editor	非対応 😢	対応
Performance Insights	対応	非対応
RDS Proxy	対応	非対応

v1 は開発用、v2 は Production ready
v1 が廃止されるわけでは無いらしい
単価は v2 の方が高く見えるが、v1 と比較して ACU サイズのオプションが多いため、結果的にコスト安になるケースが多いと思われる

所感

既存の Aurora の機能がほぼ使えるので Production でも十分に使用できそう。
Data API や Query editor など個人的に便利だった機能がなくなっているのは残念。(Amplify の RDS との Integration が v1 の DataAPI を前提としていたので今後の動向が気になる)
v1 ではスケール時にクエリリクエストが待たされてしまう(connection が切れるわけではない)点が最大の Blocker だったと思うので、ユーザ影響なしにスケールができるのはすごい(語彙力)
個人的には今年最大のアップデート

社内でも段階的に使用できないか検証していきたい。

AWS Japanを退職しました

Fri, 01 Apr 2022 22:12:03 GMT

3 年弱勤めた AWS を 2022 年 2 月付けで退職しました。

退職エントリを書くつもりはなかったのですが、自分にとって特に思い入れの強い会社だったので少しだけ書こうと思います。

あなたは誰？

主に AWS、フロントエンドを主軸にソフトウェア開発をしています。

AWS では何をやっていたの？

Prototyping Engineer (旧 Prototyping Specialist Solution Architect) というロールでお客様のクラウド導入支援を行なっていました。特に AWS 上で新たにサービスを立ち上げるお客様に対してアプリケーションのプロトタイピングを構築する部隊に所属していました。また、Amplifyという AWS が提供する mBaaS のエバンジェリスト的な活動もやっていました。

なんで辞めたの？

会社を辞めた理由は 100%ポジティブなものです。ネガティブな要素は思いつきませんでした。それくらい素晴らしい会社でした。AWS を卒業される方は皆口を揃えて同じことお仰られますが、自分も例に洩れずです。

じゃあなんで辞めたかというと、プロダクト開発に戻りたい気持ちが強くなったからです。

先程も述べた通り、Prototyping Engineer は短期間でお客様にプロトタイピングを提供することに特化したロールです。お客様ごとに異なる制約(ビジネス上の制約、組織の制約、エンジニアのスキルセットの制約..etc)を考慮して最適なアーキテクチャを提案し、短期間で最低限動くものを提供するという経験は間違いなく一生の宝になるくらい素晴らしいものでした。

業種、業態によりエンジニアのカルチャーや制約が本当に多種多様で、わずか数年という短期間で十社以上のお客様に対しプロトタイピングプログラムを提供できたことはエンジニアキャリアを数倍のスピード感で駆け抜けたような爽快感がありました。

一方で、Prototyping Engineer というロールは、長期的にプロダクトに対しオーナーシップを持つことができないという歯痒さもありましました。お客様と一緒にプロトタイピングを組み上げる期間はどんなに長くても 3 ヶ月程度であり、それ以降はお客様がオーナーシップを持ってプロダクトを育てていくことになります。我々の役割は、お客様が自走できるよう、ソフトウェアの雛形を作成し、その知見をお伝えをするところまでであり、それ以降の成果物は自分達の手を離れることになります。様々なお客様のワークロードに関与できることができる一方、プロダクトの最後までオーナーシップを持つことができないというのはどこか物足りなさ(寂しさ?)を感じるようになりました。

SA を知ったきっかけ

そもそも自分が Solution Architect(以下、SA)というロールに興味を持った経緯についても触れたいと思います。 SA というロールを知ったのは、2018 年 10 月にオープンしたAWS Startup Loft Tokyoでした。

ここは、AWS が提供するコワーキングスペースで AWS アカウントを持っているエンジニアの方であれば誰でも利用できるという場所です。(※2022.4 現在、COVID-19 の影響で一時的に閉館しています) Loft には「Ask An Expert」という無料で SA に相談ができるブースがあるのですが、ここにいた SA の方々が本当にすごかったんです。AWS に関する質問であればどんなトピックに対しても打ち返してくる。あまりになんでも答えてくれるので、あえて、Redshift Spectrum と Amplify、ECS という全く異なる分野の質問を一度に相談したことがあるのですが、どのトピックに関しても涼しい顔で的確なアドバイスをくれたのです。当時 AWS エンジニア歴 2 年目くらいの僕にとっては衝撃的な体験でした。

興奮冷めやまぬうちに Twitter で SA ロールの Hiring 説明会に関するツイートが流れてきたので、迷わず応募し、なんやかんやあって Associate Solution Architect としてオファーをいただきました。

僕の SA としての理想像はあの Loft での体験が原点になっていた気がします。

AWSソリューションアーキテクトのお仕事をご紹介するWebセミナーを企画しています。ちょっとでも興味のある方はカモン！https://t.co/1QtqF8ejJU
— Masato Kobayashi (@maccho_j) November 16, 2018

AWS で得たこと

チープな回答になりますが、多分この会社に入らなければ一生出会わなかったであろう優秀な人たちと一緒に仕事ができたことでしょうか。

AWS に入社しなければ井の中の蛙のままエンジニア人生を終えていたかもしれませんし、5 年後、10 年後に彼らのような素晴らしいエンジニアになるためにはどうすれば良いかを常に考えながら仕事ができるようになったことは、自分のエンジニアキャリアを何ステップも前進させてくれたように思います。

次何やるの?

とある Fintech 企業にて Software Engineer として働きます。その他にも色々とやりたいことがあるので、それに向けて準備を進めていこうと思っています。

最後に

だいたい自分は 3 年くらいで転職を繰り返していて退職に対してはそこまで抵抗がないタイプの人間だったのですが、AWS の退職は最後まで悩みました。それくらい Amazon のカルチャーが自分に fit していて今回の退職を後悔することもあるかもしれないです。

それでも会社を去る決意ができたのは、同僚達のような素晴らしいエンジニアとして成長するために AWS を離れて再びプロダクト開発の道に戻ることが自分にとって長期的に頑張れる気がしたからです。先にも述べた通り、AWS という環境で得たものは優秀な同僚との出会いだなとつくづく感じます。

将来、やりたい事の巡り合わせと Amazon という環境が一致したときに再びオファーレターを貰えるくらいにエンジニアとして腕を磨いていきたいと思います。

And that is why it is always Day1!

AWS Amplify × Next.js で Server Side RenderingのデプロイおよびCI/CD環境を構築する

Wed, 19 May 2021 13:46:03 GMT

本記事では、AWS Amplify と Next.js を使って SSR 構成のデプロイ、および CI/CD の構築について考えていきたいと思います。

※2021/05/19 更新 Amplify Console が SSR ホスティングをサポートしたので記事の内容を更新しました

Amplify ConsoleがNext.jsで作成されたアプリのSSRに対応しました🎉
去年9月にAmplify LibrariesがNext.js/Nuxt.jsのSSR対応したので、SSRがAmplifyで完結できるようになります！https://t.co/igYF9Vz61a #AWSAmplifyJP
— Jaga@AWS Amplify (@jagaimogmog) May 18, 2021

(参考) https://aws.amazon.com/jp/blogs/mobile/host-a-next-js-ssr-app-with-real-time-data-on-aws-amplify/

はじめに

AWS をある程度触ったことがあり、主要なサービスについては最低限理解されている前提で進めます。AWS を全く触ったことない方は、AWS 上で SSR 構築する際の課題や方針などについてなんとなく理解できれば良いなくらいの期待値で読んでいただけると幸いです。

SPA/SSR のおさらい

既に SPA,SSR の技術に精通されている方は、本章を読み飛ばしていただいても構いません。

SPA(Single Page Application)

SPA では、初回アクセス時に、アプリケーションの動作に必要な Javascript ファイルや CSS といった Asset を端末に一括ダウンロードします。単一のページを Javascript 側の処理で表示を切り替えることで高速な画面遷移を実現します。また、画面の一部を非同期に描画、更新することができ、ダイナミックな画面表示を実現することができます。

一度画面を表示してしまえば、以降のページの切り替えやデータのやり取りは非常に高速に行うことができる反面、初回アクセス時にある程度まとまった Asset を一括で端末にダウンロードするという特性上、初回のページ表示が遅くなる、もしくは、画面のレンダリングが完了するまで未完成の状態のページが画面に表示される場合があります。こういった挙動が SEO や OGP の観点で不利になることが知られています。(注 1)

SSR(Server Side Rendering)

SPA の問題を解決するために出てきたアーキテクチャが Server Side Rendering(SSR) です。

SSR では、先ほどの初回表示の問題を解決するために、API サーバとクライアントの間に、ページを生成するためのレンダリングサーバを用意します。

SPA では実際に画面を構築する作業はクライアントで行なっていましたが、SSR ではこの作業をレンダリングサーバに移譲しています。これにより、クライアントは既に構築済みのページを受け取ることができるので、初回画面の表示が高速化される場合があります。(注 2) また、未完成の状態のページが画面に表示されることがなくなるため、SEO の観点からも SPA と比較して有利であると言われています。

SPA の時と同様にクライアントから直接 API を呼び出すといったことも可能ですので、一部の画面を SSR にして、他の画面を SPA のようにクライアントで画面を構築することも可能です。

SSR のデメリットとしては、SPA の時と比較して、レンダリングサーバというインフラのコンポーネントが一つ増えることになるので、インフラの実装、運用コストが増えます。また、レンダリングをクライアントサイドで行うのか、レンダリングサーバで行うのかという実装の住み分けが必要になるため、アプリケーションの実装コスト(設計の難易度)が増えることがあります。

これらのコストと比較して SPA、SSR のどちらで実装を行うのかを検討する必要があります。例えば SEO がそもそも必要ない場合(社内向けシステムなど)であれば、構成がシンプルな SPA が選択される場合が多いです。

AWS Amplify について

SSR に限らず、AWS 上に Web アプリケーションを構築する際に避けては通れないのが AWS Amplify(以下、Amplify)です。

Amplify は、1. サーバーレスなバックエンドをセットアップするための Amplify CLI、2.フロントエンドで利用できる UI コンポーネント、3.クライアントサイドから AWS のバックエンドに接続する際に直感的な IF を提供する Amplify Library、4.CI/CD やホスティングのためのコンソール、を含む Web およびモバイルアプリ開発のためのフレームワークです。

Amplify を用いることで、AWS のバックエンドの構築、構築したバックエンドに接続するためのクライアントサイドの実装を非常に直感的に行うことが可能です。

実装の例を挙げると..

Amazon Cognito を用いた認証、認可、Social Provider を用いた OAuth 認証
GraphQL のマネージドサービスである AWS AppSync を用いたデータの CRUD 処理
きめ細やかな権限設定を伴うファイルのアップロード/ダウンロード
MQTT を用いた WebSocket 通信
AWS が提供する各種 AI サービスとのシームレスな統合(例えば、ネガポジ判定や画像アップロードして Object Detection の結果を返すといった API などが簡単に利用できます)

Amplify CLI を用いることで、これらの機能の実装をほぼゼロコストで構築することができます。専門のインフラエンジニア、バックエンドエンジニアを抱えることができない小規模な開発組織においては Amplify は非常に強力なツールになり得ます。

また、Web アプリケーションのホスティングも非常に簡単で、Amplify Console と呼ばれるホスティングサービスを用いることで、数クリックで Github や Bitbucket といったソースリポジトリの連携、CI/CD パイプラインを構築することができます。

Amplify の各機能の詳細に関しては 2020/5 に公開された BlackBelt Online セミナーを見れば体系的に学べると思います。

20200520 AWS Black Belt Online Seminar AWS Amplify from Amazon Web Services Japan

Amplify と SSR

2020.09.15 に Amplify Library が Server Side Rendering(以下、SSR) に対応しました。これまでの Amplify Library では、セッション情報やクライアントの設定情報をサーバサイドに引き継ぐ仕組みが存在しなかったため、Amplify Library は事実上クライアントサイドのみの実装に限られてきました。

今回のアップデートにより、Next.js でいうところの getServerSideProps メソッドに Amplify のクライアントの情報を引き継ぐことができるようになります。

以下、AWS 公式 Blog の抜粋

import { withSSRContext } from 'aws-amplify';
import { listMovies } from '../src/graphql/queries';

export default function Movies(props) {
  const { movies } = props;
  return (
    <div>
      {movies &&
        movies.map((movie) => (
          <div key={movie.id}>
            <h3>{movie.name}</h3>
            <span>{movie.description}</span>
          </div>
        ))}
    </div>
  );
}

// ↓ Server Side で実行されるソース
export async function getServerSideProps(context) {
  // 今回新しく追加された、withSSRContext により、クライアントの情報をServer Sideで引き継ぐことが可能
  const { API } = withSSRContext(context);
  let movieData;
  try {
    // クライアントのセッション情報(この場合Cognitoのtoken情報など)を引き継いでAppSyncにクエリを発行
    movieData = await API.graphql({
      query: listMovies,
      authMode: 'AMAZON_COGNITO_USER_POOLS',
    });
    console.log('movieData: ', movieData);
  } catch (err) {
    console.log('error fetching movies: ', err);
  }
  return {
    props: {
      movies: movieData ? movieData.data.listMovies.items : null,
    },
  };
}

Amplify が SSR のホスティングをサポート

2021/05/19 に Amplify Console がNext.js の SSR ホスティングをサポートしました。

これまでServerless Frameworkと呼ばれる Amplify CLI とは別のコマンドラインツールを用いる必要がありましたが、Amplicy Console を用いて静的サイトの時と同じ手順でホスティングを行うことが可能です。

SSR のホスティングには特別な操作は必要しません。静的サイトとしてホスティングするのか、SSR としてホスティングを行うかは Amplify Console 側で自動判定してくれます。公式ドキュメントによると、どうやらpackage.jsonの中身から SSR でホスティングすべきかどうかを判断しているようです。

デプロイされる構成としては以下のようになります。

SPA の時と同様に静的アセットはストレージサービスである Amazon S3 に配置され、CDN である Amazon CloudFront から高速に配信されます。動的コンテンツのレンダリングには Lambda@Edge が用いられており、上記コードの例では、Lambda@Edge から GraphQL のマネージドサービスである AWS AppSync に対してクエリが発行され、認証認可には Amazon Cognito が用いられています。

Amplify Console で SSR をホスティングした場合、CloudFront の設定を変更することが可能に

Amplify Console で静的サイトをホスティングした時のもう一つの変更点として、CloudFront が自アカウントで操作可能な点があります。

静的サイトのホスティングの場合、AWS サービスチームの CloudFront にホスティングされていたため、ユーザは CloudFront の管理を意識することはありませんでした。ユーザの管理対象が減るというメリットがある反面、CloudFront に対して独自の設定を行うことができないというデメリットもありました。

Amplify Console で SSR を実施する場合、CloudFront はご自身が使用されているアカウントに構築されます。これにより、例えば Amplicy Console でホスティングされたサイトに AWS WAF の設定を追加するといったことができるようになります。

Enterprise のお客様などで、自社ネットワークからのみサイトにアクセスさせたいといったユースケースにマッチしそうです。

なお、静的サイトに関しては引き続きサービスチームの CloudFront にホスティングされるためご注意ください。

まとめ

Amplify の仕組みを用いて、AWS 上に Next.js × SSR を構築する一例についてご紹介しました。 Amplify Library が SSR に対応したことで、AWS 上で SSR のアプリケーションを構築する選択肢が取りやすくなったと思います。

以上です！

補足:

注 1. 近年では多くのクローラが Javascript を実行するようになりました。そのため、数年前に問題視されていたほど、SEO の観点で SPA が不利になることは少なくなりました。ただし、クローラは全ての Javascript を実行することを保証していないため、高い SEO が求められる場合は SSR や JAMStack といった構成を検討する必要があります。
注 2.* Web のパフォーマンスに関しては様々な指標が存在します。Web のパフォーマンス改善を議論する場合は、アプリケーションの特性を理解し、どの指標を改善すべきなのかを正確に把握する必要があります。一般的に、SSR にすることで SPA より描画速度が高速になると言われることが多いですが、ケースによっては SSR にすることでユーザ体験を損なう場合もあります。(Server Side Rendering の挙動を確認するを参照) 自社のアプリケーションの課題、特性、SPA や SSR の持つ特性を正しく理解し、技術選定を行うことが大切です。

Incremental Static Regenerationをコンテナで運用するときの注意点

Sun, 27 Dec 2020 22:12:03 GMT

こちらの記事を参考に Incremental Static Regeneration(以下、ISR)をコンテナでデプロイしたときの挙動について気になった点があったのでまとめてみました。

なお、本記事では ISR の詳細ついては言及しません。それらについては元記事を参照いただければと思います。

アドベントカレンダー用の記事を書いた。結果は…

はてなブログに投稿しました #はてなブログ
Next.jsのIncremental Static RegenerationをVercel以外でやってみる - Sweet Escapehttps://t.co/gGt8nVnPiE
— Keisuke Nishitani (@Keisuke69) December 9, 2020

ISR をコンテナイメージで運用する際の注意点

Next.js の ISR では、getStaticPropsの戻り値にrevalidateオプションを付与すると、指定された秒数、クライアントにキャッシュされたコンテンツが返却されるようになります。このキャッシュはアプリケーションが動作するコンテナ内に保持されます。

以下の例であれば、最後にページを動的に作成してから最低 10 秒間は静的なページをクライアントに返却します。

export async function getStaticProps() {
  const date = new Date();
  const current = date.toLocaleString();
  return {
    props: {
      current,
    },
    revalidate: 10, // 10秒に1回ページを最新化する
  };
}

なお、revalidate は各コンテナごとにバラバラのタイミングで実施される点に注意が必要です。ロードバランサなどで複数のコンテナにルーティングされる場合、リクエストが流れるコンテナによって異なるコンテンツが返却される可能性があります。

一つのアプリケーションで一つのコンテナしか動いていない場合にはこの問題は発生しませんが、そのようなアプリケーションはあまり多くないと思います。また、この問題は revalidate の間隔が長くなればなるほど顕著になります。

例えば、revalidate: 300(5分)を指定したアプリケーションが「コンテナ A」、「コンテナ B」という二つのコンテナ上で動いている例を考えます。初回のリクエストがロードバランサを経由して「コンテナ A」にルーティングされ、その 2 分 30 秒後に「コンテナ B」にルーティングされたとしましょう。この場合、次回 revalidate のタイミングは「コンテナ A」は 2 分 30 秒後で「コンテナ B」は 5 分後になります。この期間にバックエンドでコンテンツの更新が行われた場合、最大 2 分 30 秒間、「コンテナ A」と「コンテナ B」で異なるコンテンツをクライアントに返却してしまうことになります。ロードバランサがラウンドロビンでリクエストをバランシングしている場合、ページをリロードするたびに表示内容が変わったり、ユーザによって表示されるコンテンツが異なることが想定されます。

AWS Fargate を用いて検証

AWS が提供するコンテナオーケストレーションサービスである、AWS Fargateを用いて上記の挙動を再現してみましょう。

Dockerfile とアプリケーションは元記事のものを拝借します。

export default function Index({ current }) {
  return <div>現在時刻は{current}です。</div>;
}

export async function getStaticProps() {
  const date = new Date();
  const current = date.toLocaleString();
  return {
    props: {
      current,
    },
    revalidate: 10,
  };
}

FROM node:current-alpine AS base
WORKDIR /base
COPY package*.json ./
RUN yarn install && yarn cache clean
COPY . .

FROM base AS build
ENV NODE_ENV=production
WORKDIR /build
COPY --from=base /base ./
RUN yarn build

FROM node:current-alpine AS production
ENV NODE_ENV=production
WORKDIR /app
COPY --from=build /build/package*.json ./
COPY --from=build /build/.next ./.next
COPY --from=build /build/public ./public
RUN yarn add next && yarn cache clean

EXPOSE 3000
CMD yarn start

ユーザがアクセスしたタイミングで現在時刻が表示されるシンプルなアプリケーションです。 revalidate: 10が指定されているため、10 秒間は何度アクセスしても表示時刻が変化しないことを期待します。

なお、今回は ECS に簡単にコンテナをデプロイできるAWS Copilotを用いました。

Next.js のトップディレクトリでcopilot initコマンドを発行し、Dockerfile を指定するだけでコンテナ実行に必要な VPC、ECS クラスタ、ALB、及びアプリケーションのエンドポイント URL を作成してくれます。めちゃくちゃ簡単です。

$ copilot init
Application name: isr-test # アプリケーション名を指定

Service type: Load Balanced Web ServiceX Sorry, your reply was invalid: Value is required
Service name: isr-test # サービス名を指定
Dockerfile: ./Dockerfile # Dockerfileを指定
Ok great, we'll set up a Load Balanced Web Service named isr-test in application isr-test listening on port 3000.

✔ Created the infrastructure to manage services under application isr-test.

✔ Wrote the manifest for service isr-test at copilot/isr-test/manifest.yml
Your manifest contains configurations like your container size and port (:3000).

✔ Created ECR repositories for service isr-test.

All right, you're all set for local development.
Deploy: Yes

(省略...)

f40183c0ca23: Pushed
8107d4305b97: Pushed
920b98a6ce66: Pushed
53a4abbb293c: Pushed
a40220d40eaf: Pushed
0fcbbeeeb0d7: Pushed
4e09dfc: digest: sha256:82c4b9b191ee37e520502eb3d007f4d565f7316698fcc67fe46901e8206d408c size: 2203

 # アプリケーションのエンドポイントURLが発行される。
✔ Deployed isr-test, you can access it at http://isr-t-Publi-1MHPV70ZK9M4Z-802069023.ap-northeast-1.elb.amazonaws.com.

発行された URL にアクセスすると、想定通りにアプリケーションが動作していることがわかります。

デフォルトの設定だと、コンテナは一つしか動いていないため、copilot の manifest ファイルからコンテナを増やす設定を加えてみます。

copilot が作成したcopilot/<サービス名>/manifest.ymlのcountから起動するコンテナの数を変更します。

# Number of tasks that should be running in your service.
count: 10

サービスのデプロイコマンドで変更をクラウドに反映します。

$ copilot svc deploy

再度、ブラウザにアクセスしてみると、ページを表示させる度に表示される内容が毎回変わってしまうことが確認できます。これは先ほど述べた revalidate のタイミングが異なるため、ルーティングされるコンテナごとに異なるコンテンツ(今回の場合現在時刻)が表示されてしまうためです。

まとめ

コンテナに限らずですが、ローカルにキャッシュデータを保持する特性上 revalidate のタイミングが異なる点は意識する必要があります。コンテンツの表示に高い一貫性を求められない場合は大きな問題にはならないかもしれません。

これらの挙動が許容できない場合は、revalidate の間隔を短くする、もしくは厳密な一貫性が求められるページのみ SSR や、クライアントから API を Call するなどなどして対応する必要があります(その場合、リクエストの度にバックエンドに負荷をかけることになるため ISR 本来の旨味が少なくなります)。Vercel でデプロイする場合 CDN のキャッシュと合わせてその辺りをうまくハンドリングしているようです。

フロントエンドも SPA、JAMstack、SSR、そして ISR とアーキテクチャの選択肢が増えてきましたが、それぞれの特性をよく理解して技術選定をするのが良さそうです。

Gatsby製のサイトをAmplify Consoleでホスティングすると、特定のページのURLをブラウザに打ち込んだ際にTOPページにリダイレクトされてしまう

Thu, 10 Dec 2020 04:59:03 GMT

Gatsby 製のサイト(このサイト)を Amplify Console でホスティングする際にハマったのでメモ。

何が問題だったかというと、特定のページ(https://whnyab.com/amplify-ssr-cicd)にブラウザから直接アクセスしても全て TOP ページ(https://whnyab.com/)にリダイレクトされてしまう状態だった。全てのアクセスが TOP ページにアクセスされてしまうため、特定の記事を SNS 等でシェアすることができなくなっていた。しかもローカル環境では再現しなかったので気がつくまでに結構時間が立っていた。

解決策

初めは Gatsby のルーティングの設定を疑っていたが、どうやら Amplify Console のリダイレクトの設定が問題のようだった。

Amplify Console ではマネジメントコンソールから Web ページのリダイレクトの設定を細かく設定できる。SPA のサイトをホスティングする際は、多くの場合でデフォルトの設定で問題ないのだが、Gatsby のサイトをホスティングする場合はリダイレクト設定を以下のように修正する必要がある。

// (before)
[
  {
    "source": "/<*>",
    "target": "/index.html",
    "status": "404-200",
    "condition": null
  },
  {
    "source": "</^[^.]+$|\\.(?!(css|gif|ico|jpg|js|png|txt|svg|woff|ttf|map|json)$)([^.]+$)/>",
    "target": "/index.html",
    "status": "200",
    "condition": null
  }
]

// (after)
[
  {
    "source": "/<*>",
    "target": "/index.html",
    "status": "404-200",
    "condition": null
  }
]

設定箇所はこちら。

Amplify Console の Issueで同じ事象でハマっている人がいて助かった。

Gatsby を Amplify Console にホスティングしようとすると必ずこの問題に直面するはずなんだけど、参考になる情報が少なくて苦労した。

みんなバリバリ Amplify Console を使いこなしていてそもそも問題にならないのか、Gatsby ユーザが誰も Amplify Console 使ってないのかどっちだろう..

AWS Amplify + AWS AppSyncでUnitテスト書く時の How to

Fri, 04 Dec 2020 22:12:03 GMT

概要

Amplify Framework + AWS AppSync でフロントエンドの Unit テスト書く時のハウツーをご紹介します。本記事ではアプリケーションの実装に React を用いていますが、基本的な考え方は Vue などの他のフレームワークでも同じです。

想定読者

Amplify 触ったことある
AppSync 触ったことある
jest を使った Unit テストを書いたことがある
React のソースが読める(と、尚良し)

Amplify、AppSync あまり触ったことない！という方は Amplify CLI GraphQL Transform とディレクティブで AppSync+DynamoDB をいじってみよう！(@model @auth, @key)の記事を参考にいただけると良いと思います！

Amplify で Unit テストを書く方法

API を Mock する

一般的にフロントエンドの Unit テストを書く場合は、外部の API 通信を Mock することが多いと思います。例えば以下のような axios を用いた API 通信を Mock する場合は、

// return { user: { name: 'taro', age: 22 }}
const user = await axios.get('/user/1').then((resp) => resp.data);
<User user={user} />;

jest.spyOn(axios, 'get').mockReturnValue(
  Promise.resolve({
  user: {
     name: 'taro',
     age: 22
  }
});

といった感じで、API 呼び出しを行う関数を Mock し、想定されるレスポンスに対し DOM が正しく描画されるか等のテストを行います。

Amplify で Unit テストを書く場合も基本的な考え方は同じです。Amplify Framework は AWS バックエンドとシームレスに連携できる API をたくさん提供しており、それらの API を Mock することで Unit テストを実装していきます。

例えば、S3 にファイルをアップロード処理を Mock する場合は

import { Storage } from 'aws-amplify';

const file = e.target.files[0];
// return { key: "<file_path>" }
Storage.put('example.png', file, {
  contentType: 'image/png',
})
  .then((result) => console.log(result))
  .catch((err) => console.log(err));

import { Storage } from 'aws-amplify';

jest.spyOn(Storage, 'put').mockReturnValue(
  Promise.resolve({
    key: 'example.png',
  })
);

この様に、想定されるレスポンスの通りに Mock するだけです。他にも、よく使用する Mock の例いくつかあげます。

例 1. Cognito の認証済みユーザ情報を取得する

import { Auth } from 'aws-amplify';

Auth.currentAuthenticatedUser()
  .then((user) => {
    // ユーザ情報を用いた処理
    console.log(user);
  })
  .catch((err) => {
    console.log(err);
  });

Mock

import { Auth } from 'aws-amplify';

jest.spyOn(Auth, 'currentAuthenticatedUser').mockReturnValue(
  Promise.resolve({
    username: 'myuser',
    attributes: {
      email: 'test@test.com',
      email_verified: true,
      phone_number: '08012345678',
      // ...other attributes
    },
    // ...other parameters
  })
);

例 2. GraphQL を用いて AppSync からデータを fetch する

import { API, graphqlOperation } from 'aws-amplify';

API.graphql(graphqlOperation(`query ListTodos() {
  listTodos() {
    items {
      id
      name
    }
    nextToken
  }
}`).then(result => {
  // GraphQLのfetch結果の処理
  console.log(result)
}).catch(err => {
  console.log(err)
});

Mock

jest.spyOn(API, 'graphql').mockReturnValue(
  Promise.resolve({
    data: {
      listTodos: {
        items: [
          { id: 'todo1', name: 'todo_name_1' },
          { id: 'todo2', name: 'todo_name_2' },
        ],
      },
    },
  })
);

Amplify から AppSync の Unit テストを書く時に詰まるところ

さて、ここから本題である Amplify AppSync で Unit テストについて説明していきます。上の例で説明した様に基本的には関数(API.graphql)を Mock する方法で問題ありません。しかし、実際にテストを書いていこうとするといくつか問題が出てきます。

今回は、ボタンを押すと TODO が登録され、リアルタイムに新しい TODO が表示されるアプリケーションを例に見ていきましょう。

問題 1. API.graphql を Mock するだけでは一つのテストで複数クエリが発行される場合に対処できない

例えば、コンポーネント作成時にデータの fetch と Subscribe を同時に行うケースなどです。

import React, { useEffect, useReducer } from 'react';
import { API, graphqlOperation } from 'aws-amplify';
import { listTodos } from './graphql/queries';
import { onCreateTodo } from './graphql/subscriptions';
import { createTodo } from './graphql/mutations';
import uuidV4 from 'uuid/v4';

const initialState = { todos: [] };

function reducer(state = initialState, action) {
  switch (action.type) {
    case 'SET_TODOS':
      return { todos: action.todos };
    case 'ADD_TODO':
      return { ...state, todos: [...state.todos, action.todo] };
    default:
      return state;
  }
}

const GraphQLApp = () => {
  const [state, dispatch] = useReducer(reducer, initialState);

  // (1) データをfetch
  useEffect(() => {
    getData();
  }, []);

  // (2) Subscriptionを開始
  useEffect(() => {
    const subscription = API.graphql(graphqlOperation(onCreateTodo)).subscribe({
      next: (payload) => {
        const todo = payload.value.data.onCreateTodo;
        dispatch({ type: 'ADD_TODO', todo });
      },
    });
    return () => subscription.unsubscribe();
  }, []);

  const getData = async () => {
    try {
      const result = await API.graphql(graphqlOperation(listTodos));
      dispatch({ type: 'SET_TODOS', todos: result.data.listTodos.items });
    } catch (err) {
      console.log('error fetching todos...', err);
    }
  };

  const clickButton = () => {
    const name = new Date() + '_TODO';
    API.graphql(
      graphqlOperation(createTodo, {
        input: {
          id: uuidV4(),
          name: name,
        },
      })
    );
  };

  return (
    <>
      <button className="create_button" onClick={clickButton}>
        CreateTodo
      </button>
      <ul>
        {state.todos.map((v, k) => {
          return (
            <li key={k} className="todo">
              No.{k + 1}：{v.name}
            </li>
          );
        })}
      </ul>
    </>
  );
};
export default GraphQLApp;

このアプリケーションではコンポーネント作成時に 2 種類のクエリを発行しています。「(1) データの fetch」では Query を発行し、「(2) Subscription を開始」では Subscription を発行しています。API.graphql の Mock には一つのパターンのレスポンスしか記述できないので、別の方法を検討する必要があります。一つのアイディアとして、API.graphql を Mock する代わりに、Model を作成し、この Model を Mock 化します。

import { API, graphqlOperation } from 'aws-amplify';
import { listTodos } from './graphql/queries';
import { createTodo } from './graphql/mutations';
import { onCreateTodo } from './graphql/subscriptions';
import uuidV4 from 'uuid/v4';

const TodoModel = {
  listTodos: () => {
    return API.graphql(graphqlOperation(listTodos));
  },

  createTodo: (name) => {
    return API.graphql(
      graphqlOperation(createTodo, {
        input: {
          id: uuidV4(),
          name: name,
        },
      })
    );
  },

  subscribeOnCreateTodos: () => {
    return API.graphql(graphqlOperation(onCreateTodo));
  },
};

export default TodoModel;

GrapQLApp.js からこの Mock を呼び出します。

import React, { useEffect, useReducer } from 'react';
import TodoModel from './TodoModel';

const initialState = { todos: [] };

function reducer(state = initialState, action) {
  switch (action.type) {
    case 'SET_TALKS':
      return { todos: action.todos };
    case 'ADD_TODO':
      return { ...state, todos: [...state.todos, action.todo] };
    default:
      return state;
  }
}

const GraphQLApp = () => {
  const [state, dispatch] = useReducer(reducer, initialState);

  useEffect(() => {
    getData();
  }, []);

  useEffect(() => {
    const subscription = TodoModel.subscribeOnCreateTodos().subscribe({
      next: (payload) => {
        const todo = payload.value.data.onCreateTodo;
        dispatch({ type: 'ADD_TODO', todo });
      },
    });
    return () => subscription.unsubscribe();
  }, []);

  const getData = async () => {
    try {
      const result = await TodoModel.listTodos();
      dispatch({ type: 'SET_TALKS', todos: result.data.listTodos.items });
    } catch (err) {
      console.log('error fetching todos...', err);
    }
  };

  const clickButton = () => {
    TodoModel.createTodo(new Date() + '_TODO');
  };

  return (
    <>
      <button className="create_button" onClick={clickButton}>
        CreateTodo
      </button>
      <ul>
        {state.todos.map((v, k) => {
          return (
            <li key={k} className="todo">
              No.{k + 1}：{v.name}
            </li>
          );
        })}
      </ul>
    </>
  );
};
export default GraphQLApp;

Mock は以下のように記述できます。

// QueryのMock
jest.spyOn(TodoModel, 'listTodos').mockReturnValue(
  Promise.resolve({
    data: {
      listTodos: {
        items: [
          { id: 'todo1', name: 'todo_name_1' },
          { id: 'todo2', name: 'todo_name_2' },
        ],
      },
    },
  })
);

// SubscriptionのMock (Obervableについては後ほど解説)
let emitOnCreateTodos;
jest.spyOn(TodoModel, 'subscribeOnCreateTodos').mockReturnValue(
  new Observable((observer) => {
    emitOnCreateTodos = (v) => observer.next(v);
  })
);

このように API.graphql を Mock するのではなく、Model を Mock することで、一度に複数の API.graphql を呼び出す場合のテストにも対処することが可能です。

問題 2. Mutation トリガーの Subscription 処理をどのようにテストするか

GraphQLApp.js の例では、新しく TODO を作成(Mutation)したことをトリガーに Subscription が Mutation の更新を検知し、store の更新を行っています。

const subscription = TodoModel.subscribeOnCreateTodos().subscribe({
  // Mutationをトリガーにここ↓が呼び出される
  next: (payload) => {
    const todo = payload.value.data.onCreateTodo;
    dispatch({ type: 'ADD_TODO', todo });
  },
});

「Mutation をトリガーに正しく新規 TODO が表示されること」をテストするにはどのようにすれば良いでしょうか？API は Mock されているため、実際に AppSync の Subscription、Mutation を呼び出すわけにはいきません。「問題 1」でも少し触れましたが、Subscription の Mock は以下のように行っています。

let emitOnCreateTodos;
jest.spyOn(TodoModel, 'subscribeOnCreateTodos').mockReturnValue(
  new Observable((observer) => {
    emitOnCreateTodos = (v) => observer.next(v);
  })
);

subscribeOnCreateTodos: () => {
  return API.graphql(graphqlOperation(onCreateTodo));
};

API.graphql(graphqlOperation(onCreateTodo))は Subscription クエリを発行する場合、Observable クラスを返却しています。結論から言うと、この Mock で返却している Observable を発火させれば、Mutation をトリガーに store を更新することができる処理をテストできます。

テストコードは以下のようになります。

it('test subscription', async () => {
  await act(async () => {
    wrapper = mount(<GraphQLApp />, { attachTo: container });
    await waitForExpect(() => {
      wrapper.update();
      // (1) Mutation発火前の画面に表示されているTODOの数をカウント
      const initialRenderdTodoLength = wrapper.find('.todo').length;

      // (2) Observableを発火(擬似的にSubscriptionがAppSyncからメッセージを受け取ったことを再現)
      emitOnCreateTodos({
        value: {
          data: {
            onCreateTodo: {
              id: 'todo3',
              name: 'todo_name_3',
            },
          },
        },
      });
      wrapper.update();
      // (3) 画面に表示されているTODOのカウントが1つ増えていることを確認
      expect(wrapper.find('.todo').length).toBe(initialRenderdTodoLength + 1);
    });
  });
});

これで、next: (payload)に emitOnCreateTodos に渡したデータを payload で受け取ることができます。 Query/Mutation/Subscription の全体のテストコードは以下になります。

import MyTest from './MyTest';
import waitForExpect from 'wait-for-expect';
import { act } from 'react-dom/test-utils';
import GraphQLApp from './GraphQLApp';
import Observable from 'zen-observable';

jest.spyOn(TodoModel, 'listTodos').mockReturnValue(
  Promise.resolve({
    data: {
      listTodos: {
        items: [
          { id: 'todo1', name: 'todo_name_1' },
          { id: 'todo2', name: 'todo_name_2' },
        ],
      },
    },
  })
);
jest.spyOn(TodoModel, 'createTodo').mockReturnValue(
  Promise.resolve({
    data: {
      createTodo: {
        id: 'todo3',
        name: 'todo_name_3',
      },
    },
  })
);
let emitOnCreateTodos;
jest.spyOn(TodoModel, 'subscribeOnCreateTodos').mockReturnValue(
  new Observable((observer) => {
    emitOnCreateTodos = (v) => observer.next(v);
  })
);
let wrapper;
let container;

it('test query', async () => {
  await act(async () => {
    wrapper = mount(<GraphQLApp />, { attachTo: container });
    await waitForExpect(() => {
      wrapper.update();
      // Queryで取得したTODOデータが2件表示されていること
      expect(wrapper.find('.todo').length).toBe(2);
    });
  });
});

it('test mutation', async () => {
  await act(async () => {
    wrapper = mount(<GraphQLApp />, { attachTo: container });
    await waitForExpect(() => {
      wrapper.update();
      // Create Todoボタンをクリック
      wrapper.find('.create_button').first().simulate('click');
      // Mutationが発行されたこと(対象の関数が呼び出されたこと)
      expect(TodoModel.createTodo.mock.calls.length).toBe(1);
    });
  });
});

it('test subscription', async () => {
  await act(async () => {
    wrapper = mount(<GraphQLApp />, { attachTo: container });
    await waitForExpect(() => {
      wrapper.update();
      // (1) Mutation発火前の画面に表示されているTODOの数をカウント
      const initialRenderdTodoLength = wrapper.find('.todo').length;

      // (2) Observableを発火(擬似的にSubscriptionがAppSyncからメッセージを受け取ったことを再現)
      emitOnCreateTodos({
        value: {
          data: {
            onCreateTodo: {
              id: 'todo3',
              name: 'todo_name_3',
            },
          },
        },
      });
      wrapper.update();
      // (3) 画面に表示されているTODOのカウントが1つ増えていることを確認
      expect(wrapper.find('.todo').length).toBe(initialRenderdTodoLength + 1);
    });
  });
});

テストを実行してみます

yarn test

無事全てのテストがパスしました！

[Amplify] @httpディレクティブでCognito Authorizer付きAPI Gatewayを Amplify Libraryから呼び出そうとすると"Template transformation yielded an empty response."エラーになる

Sat, 14 Nov 2020 22:12:03 GMT

掲題の通り、Amplify の @http ディレクティブを使って AppSync から Cognito Authorizer を指定した API Gateway を Amplify Library から呼び出そうとすると “Template transformation yielded an empty response.” になりました。

AppSync ログを Cloudwatch Logs に出力し、原因を調べたところ、どうやら resolver の中で Unauthorized エラーになっているようでした。

AppSync の Authorizer に Cognito UserPool を指定する場合、Authorization ヘッダーの認証情報は API Gateway にも引き継がれるので問題ないかと思っていましたが、同じ Cognito UserPool を Authorizer に指定しているにも関わらず Unauthorized エラーになります。

原因としては、AppSync はaccess tokenを用いて認証しているのに対し、API Gateway はId Tokenを使用しているためでした。

Amplify Library で、AppSync のカスタムヘッダーに Id Token を指定すると解決しました。

Amplify.configure({
  API: {
    aws_appsync_authenticationType: 'AMAZON_COGNITO_USER_POOLS',
    aws_appsync_graphqlEndpoint:
      "https://xxxxxxxxxxxxxxxx.appsync-api.us-east-1.amazonaws.com/graphql",
    aws_appsync_region: "us-east-1",
    // Authorization HeaderにIdTokenを指定
    graphql_headers: async () => {
      const session = await Auth.currentSession();
      return {
        Authorization: session.getIdToken().getJwtToken(),
      };
    },
  },
  (snip..)

複数のマイクロサービスを一つの AppSync で IF を統一するなど、クライアントにバックエンドを意識させない仕組みとして@http ディレクティブは非常に有用だと思うので今後も積極的に活用していきたいと思います。