はじめに
ここでは僕が新人研修で学んだことを伝えたいと思います。研修期間は3ヶ月です。会社としては上流工程から下流工程までの案件を引き受けている SIer 企業です。その企業がどのような新人研修をしたかというのを参考にしていただけたらなと思います。
新人研修新人研修で行ったことは以下の通りです。
- 基本的な知識のインプット(SQL, Java, Git, etc..)
- 社内サービス改善
- 社内サービス作成
そしてここでは3つ目の社内サービスの作成について話していきたいと思います。
サービス概要
- サービスの内容
- 社内向け書籍購入ウェブアプリケーション
- 使用用途
- 社員が読んだ書籍のレビューをし書籍の情報共有をしあう
- 使用した言語
- JavaScript
- フロントエンド:React
- バックエンド:Node.js
- JavaScript
- インフラ環境
- AWS
この開発は新人8人(フロントエンド:4人、バックエンド:4人)で行いました。僕はバックエンド側の担当していたためバックエンド側の話をしたいと思います。またバックエンドの中でもAPI実装チームとインフラ構築チームの2人ずつに分かれて開発を進めていきました。
インフラ環境
ここではこのサービスのインフラ環境の説明をしていきます。MicrosoftやGoogleもクラウドサービスを提供していますが今回はAWSのクラウドコンピューティングシステムを利用してインフラ環境を構築しました。
環境としてはこんな感じです。
流れとしては、クライアントからリクエストを送信し、そのリクエストを Route 53 が受信します。その受け取った情報を Amazon CloudFront に流し Nginx へとリクエストを送ります。その受け取った情報をもとに戻り値を作成しクライアントに適切な情報を返します。
それでは今回使用したツールの紹介をしていきます。
Route 53
Route 53 はAWSの一つです。特徴としては以下があります。
- SLA 100%
- ドメイン登録
- 低価格
• SLA
SLA は Service Level Agreement の略です。サービスレベル合意書やサービス品質保証などと日本語では訳されます。サービス提供者と利用者の間で結ばれるサービスレベル(定義、範囲、内容など)に関する水準を細かく規定しておき、これを破った場合のペナルティについての契約書です。主に通信サービスやクラウドサービス、連絡サーバーで直っでよく用いられます。
• ドメイン登録
Route 53 では新しくドメイン名を登録することができます。また他のレジスト等で登録したドメインをRoute 53 上に移管することもできます。しかし、一度登録したドメイン名は変更できません。
• 低価格
Route 53 の場合使用した分だけ支払う仕組みなので使う側としては安心できるサービスとなっています。
そして Route 53 では負荷が高くなれば自動的にサーバの台数を増やしたりサーバを強化する機能が備わっています。このような性能の良さが Route 53 には備わっています。
Amazon CloudFront
Amazon CloudFront はCDN(Contents Delivery Network)の一つで、高い安全性とデベロッパーの利便性を備えています。
CloudFront を導入しているサービスとして以下の事例があります。
- Amazon Prime Video
- Hulu
この用に多量のアクセスやデータのリクエストが来たとして対処できるような機能が備わっています。CloudFront の場合、使用した量だけ支払う料金システムになっています。また50GBのデータ送信、200万件のHTTPSリクエストなら1年間無料となっているのでAWS初心者の方でも始めやすいかなと思います。
VPC
Virtual Private Cloud の略でAWSアカウント内に構築できる仮想ネットワークです。図にようにVPC内でEC2などのAWSのサービスを配置することができます。またVPCは複数のVPC間の接続も可能です。ネットワーク環境の構築の際、ハードウェア、回線、データセンターなど用意すべきものが多いためコストと時間がかかります。しかし、AWSでVPCをネット環境として準備すると数分でネットワークを構築することでができます。
EC2
AWSを利用する際によく使われるのが EC2 です。EC2は「Amazon Elastic Compute Cloud」の略でクラウド環境において様々な役割を担ってくれます。EC2を利用することで得られるメリットをいくつか挙げてみました。
- 使用した分だけ課金
- インフラ環境構築時間の短縮
- 冗長化の負荷分散
• 使用した分だけ課金
EC2は従量課金になっているため、使用した分だけの請求が行われます。また3つの料金形態が存在するためそれぞれのサービスの目的によって料金のお得度が変わるため使用する際は料金形態のチェックも必要になるでしょう。
• インフラ環境構築時間の短縮
インフラ環境の構築においてハードウェア設定が必要な物理サーバーなどを使用する場合、設定完了まで数日かかることもありますが、EC2は数分あれば立ち上げが完了します。この圧倒的スピードで環境作成ができるEC2はプロジェクトにメリットを与えるでしょう。
• 冗長化の負荷分散
仮想サーバの複製などが容易にできるため複数の台数を用意することで安定したサーバの運用が可能です。そのためシステムのトラブルで、万が一サーバがダウンしたとしても他のサーバでサービスを運用することが可能です。
Nginx
NginxはWebサーバの一つで、Apacheと比べて高速で大量処理が得意といったメリットがあります。静的コンテンツ処理には適しているためBookclubではNginxを採用しました。また設定も簡単にできるため管理者側としては使いやすいサービスになっています。しかし、大量の動的コンテンツの処理には向いないため、動画を扱ったWebサイトなどの運営には適さないでしょう。また初心者に対しての情報が少ないというデメリットもあります。
2021年6月時点でのWebサーバソフトウェアのシェア(出典:W3Techs.com)ではApacheを抜きNginxが1位となっています。
PM2
PM2はNode.jsをアプリケーションごとに本番環境で起動するためのツールです。またログ管理やモニタリング(CPUやメモリ)が可能です。Node.jsアプリケーションのプロセスの状態を常に監視しており、プロセスを自動で再起動させる機能を備えています。PM2は3つのプロダクトがあり、今回のBookclubではPM2 Runtimeを使用しています。
↑PM2 Runtimeはチェックが必要
Node.js
Node.jsはJavaScriptをサーバサイドでも動くようにしてくれるツールです。詳しくいうと、ブラウザ上で動作するJavaScriptをOS上でも動くようにしたのがNode.jsです。しかし、Node.jsはDjangoやLaravelなどのWebフレームワークではなくあくまでもJavaScriptの実行環境です。
Node.jsの特徴は「軽量」であるということです。例えば、リアルタイムで複数の人が使用する場合でもスムーズに動作してくれるという魅力があります。
開発
開発ではAPI作成からテストまでを行いました。順序としては、API仕様書を作成し、それに沿ったコードを実装をしていきました。そしてその実装が正しいか、またサーバの強度は十分に足りているかというテストをしました。
開発の中で僕が印象に残ったものをピックアップし紹介していきます。
- Swagger
- Advanced REST client / Postman
- Jmeter
Swagger
開発で一番最初に躓いた場面がこのSwaggerでした。Swagger とは REST API を構築するためのオープンソースのフレームワークのことです。APIも知らなかった僕はこれがどう開発でいかされるのか全く想像がつきませんでした。書き方が全然わからない中で講師の方に紹介していただいたのがSwagger Editorでした。ここではすでに Swagger のコードが書かれているため、これを参考にサービスの API を作っていきました。
Advanced REST client / Postman
ローカル環境で開発をしている際にHTTPのリクエスト送信やレスポンス確認をするために使用したのが Advanced REST client と Postman です。curlをたたいて実行はできますが
Advanced REST client
これは Google の拡張機能で色んな処理をブラウザ上で実行することができるため便利です。また頻繁に使うリクエストの保存、履歴参照の機能も備わっています。
Postman
これは有名な Web API のテストクライアントのひつとです。様々なテストのシナリオを実行することができます。また、認証、テスト、ドキュメント作成、バージョン管理などいろんな種類の要素を統合してテスト開発ができるため、ログイン、非ログインのユーザの実装も簡単にできる便利なツールです。API設計・開発する際は是非使ってみて下さい。
Jmeter
Jmeter の説明をしていく前にテそもそもストではどういったことを行なっていったのかの説明から始めます。
テスト
開発で欠かせないのがテストです。テストはもちろんしたことがなかったので、何をどのようにしたらいいか、またどのようなエビデンスを取らなければいけないのかすらわかっていませんでした。
ここで僕たちが行ったテストで必要であった要素を紹介します。
- 全ての想定される実装の洗い出し
- 想定された戻り値を返しているか
- サーバの負荷強度
全ての想定される実装の洗い出し
これに関しては自分たちが書いたコードの中で実装されているAPIの洗い出しをしました。
しかし、今思うとディシジョンテーブルを使用するべきだったなと思います。ディシジョンテーブルを使用することでテストの抜け漏れを防ぐことができます。また、テスト直前にディシジョンテーブルを作成するのではなく開発前、設計の段階でディシジョンテーブルを作成する方がよりベターです。
想定された戻り値を返しているか
この想定された戻り値に関しては先ほど紹介した Swagger を参照し、どのような戻り値を返さなければいけないのかの確認が必要です。このAPI開発ではAPI仕様書をもとに開発が進められているため、フロント側もバックエンド側も開発を進めてAPI仕様書を見て実装していかなければいけません。ここで使用するツールは Advanced REST client や Postman などももちろん使えますが、この後に紹介する Jmeter を使うことも可能です。
サーバの負荷強度
このサーバの負荷強度でとても役に立ったのが Jmeter です。この Jmeter は良いところは自動的にいくつもの実装を行なってくれる、いわゆる自動化です。この自動化テストを行うことでサーバの強度を図ることができます。
例えば1分間の間にn回サーバにアクセスが来た場合(サイトを開いた、投稿した、投稿を削除した、etc...)の実行結果を出すことができます。この数が多い方がサーバの強度が高いことを意味します。しかし、ここで重要なのがCDNを含まないようにすることです。僕たちは最初いくらnの回数を上げても全てのリクエストが正常に返ってくるため、サーバの強度高いなと勘違いしていました。しかしこれは間違いで僕たちが測っていた強度はサーバではなく CloudFront の強度を測っていたのです。そのため、サーバの負荷テストを行うときはCDNを外すという作業を忘れないようにしなければなりません。
最後に
今回は新人研修で作ったサービスについて書いてみました。いかがでしたでしょうか?
インフラ周りなどの担当していない部分についてはまだまだ勉強不足な面がありもっともっと知識をつけなければいけないなとこの投稿を書きながら思いました。
この研修での1番の収穫は「知らないことばかりだな」と知らないことを知ることができたことです。この先も勉強を続けて知らない部分知り、いろんなものを吸収していこうと思います。
最後まで読んでいただきありがとうございました。