最近のアウトプットについて報告
＜報告内容＞
今回は初めて技術ブログ以外の話題を書かせて頂きます。
まずは、1ヶ月近くアウトプットが止まっておりますが、もう少し続きそうですという話題を書きにきました。
現在やっているお仕事が少し立て込んでおり、アウトプットする時間が足りない状況です。
個人開発のGitHubのコミットはちょこちょこコミットを上げてたりはしてるのですが、ブログを書く時間がどうしても捻出できず....申し訳ありません。
(※スクショの準備であったり、文字を書く量が多くなるのでどうしても時間が掛かってしまい捻出できませんでした。)
直近までマイクロサービスに関連する記事を書いておりますが、結論としてはLaravelとRailsのバックエンドコンテナ分けが完了したので、記事は現在進行形で書いております。
あとは認証方式の設計で悩んでおりますが、その問題を解決したら手を動かしてアウトプットしたいと思っております。
※記事もパート分けして書くのか等の検討もしてます。
(例えば、パート1では最初にフロントエンドとバックエンドの繋ぎ込みまで書き、パート2ではバックエンドのコンテナ間で通信をする話題などを書く...等)
以上、報告となります。
今週学んだ話題：AWS負荷テストについて調べてみた
＜目次＞
・何故この記事を書こうと思ったのか？
・学んだ内容
・今回勉強するにあたって参考にしたサイト
・感想
・今後の記事話題
以上の構成で記事は進みます。
＜何故この記事を書こうと思ったのか？＞
結論、「負荷テストってできるのかな？どうなんだろう？」って思い調べたことを記事にしてみました。
具体的に話すと、私は個人開発よりAWSを利用してサーバーの構築してデプロイまでは経験したことがあるんですけど、ロードバランサーを使った負荷分散ってやったことなくて勉強中でして、そんな中である一言を言われたんです。
「まぁ....ロードバランサー設定できても、個人開発でそんな負荷がかからないでしょ(真顔)」って言葉をかけられた時に電流が走りましたね。笑
でも、そんなこと言われても世の中のインフラ構築してる人はどんな感じで、負荷テストしてるんだろうって思い調べてみました。
＜学んだ内容＞
早速、負荷テストについてざっくり調べましたが、私が個人的に良さそうだなぁと思ったのは「AWSソリューション」でした。
その理由は「Gatling」や「JMeter」といったテストツールもサポートしつつ、AWSのGUI上でもパラメーター設定して負荷テストを実行できるとのことで、出来ることが単純に広くて良いなぁと感じました。
あとは調べてみてびっくりしましたが、AWSってEC2インスタンスに向けて負荷試験を行う時は、ユースケースによって申請が必要だそうです。(後述サイトURL参照)
他にも負荷テストなので「負荷テストの目的」や「想定シナリオ」があると思いますので、そういった観点の勉強も他のエンジニアの方はどうやってやっているのか？参考にしつつ勉強が必要だと感じました。
＜今回勉強するにあたって参考にしたサイト＞
__AWS負荷テスト話題
大規模な負荷テストを実行可能。「Distributed Load Testing on AWS」 を試してみる - builders.flash☆ - 変化を求めるデベロッパーを応援するウェブマガジン | AWS
※「テストを実行してみよう！」の項目もあり、負荷テストこんなか感じでやるのか〜って視覚的に理解しやすいと思います。
__テスト申請関連の記事
※AWS公式のテストポリシーです、改行がなくて少し見づらいのですが、公式の情報をベースにテスト計画を立てましょう！
Amazon EC2 インスタンスに構築した環境への負荷テストを実施するには申請が必要でしょうか？ | DevelopersIO
※良くまとめられてみやすいかったです、どんなユースケースであればテスト申請する必要があるのか？とか、特定サイズのインスタンスでは申請負荷など情報が見やすく閲覧できます。
＜感想＞
AWSって本当になんでも出来てしまって驚きでした。
また、調べるだけで満足せず実際に手を動かしてみたいので、今後AWSロードバランサー構築後に、負荷分散できてるか検証までをやってみたいと思ってます。
※ロードバランサーは確か無料枠から外れているので、負荷テストやったりしたら、いくらになるのか？とか色々情報を調べてから実践したい所ですね！
＜今後の記事話題＞
今後書きたい記事は2つあります。
記事が出来次第、更新したい所です。
・マイクロサービスについて(フロントからバックエンド繋ぎ込み編)
・AWS負荷分散の話
__ロードバランサー構築編
__負荷テストを構築編
以上です、また次の記事で会いましょう！
マイクロサービス勉強してみた(Dockerfile構築編)
＜目次＞
・何の記事？
・なぜこの記事を書こうと思ったのか？
・最終的なファイル構成
・立ち上げてみた
・今後のマイクロサービス関連の記事について
＜何の記事？＞
マイクロサービスへの小さな1歩となる記事ですが、フロントエンドとバックエンドをコンテナ単位で分けたDockerfileの構築が完了したのでアウトプットするための記事です。
マイクロサービスに興味がある方は是非、閲覧してみてください。
＜何故この記事を書こうと思ったのか？＞
過去の記事でフロントNuxt バックエンド Laravelのプロジェクトを組もうと思いますという言葉を書いており実現できた為、記事を書こうと思います。
＜最終的なファイル構成＞
以下のような、ファイル構成になりました。
backendフレームワーク:Laravel
forntendフレームワーク:Nuxt.js
infraファイルはファイル名称通り、mysql情報やnginxなどの情報が格納されてます。
Dockerfileのコンテナの構成です。
＜立ち上げてみる＞
うまい具合に各コンテナが立ち上がりました。
Dockerfileを見て貰えばポートはわかると思いますが、フロントエンドとバックエンドに接続してみます。
3000ポート : フロント
9000ポート : バックエンド
見事にアクセスできてますね！
＜今後のマイクロサービス関連の記事について＞
以下の3つの点にフォーカスして記事を書きたいと思ってます。
1つ目：過去の記事の例えで書いていた掲示板CRUDバックエンドを作成し、フロントエンドに繋ぎ込みまでを次回記事からやっていく予定
(※そこから枝葉を生やすようにバックエンドコンテナも増やしていきたい。)
2つ目：他の人が制作したマイクロサービス構成を閲覧し、今回の記事よりも良い構成が見つかればそれを記事にして共有したい。
3つ目：少し先の話になるがマイクロサービスの認証設計がSSO方式だと、認証バックエンドコンテナに負担がかかりすぎるので良い設計を探し見つかり次第記事にしたい。
(※前回記事のDB共有はNG編をみてもらうと分かるが、DB共有はNGなのでログインユーザー情報を扱う場合は認証バックエンドから情報をもらう必要がある、それ故に負荷が大きいとみてます。)
記事を閲覧していただいてありがとうございます、引き続きマイクロサービスの記事は書いていきます。
また次の記事でお会いしましょう。
マイクロサービス勉強してみた (共有DBはNG編)
＜目次＞
※今記事から目次を試験的に置いてみます。
・何故この記事を書こうと思ったのか？
・今回勉強するにあたって参考にしたサイト
・結論
・何故そんなことが起きてしまうのか？(※結論に対して)
・DBはどう扱うべきなのか？
・学んだ感想
以上の構成で記事は進みます。
＜何故この記事を書こうと思ったのか？＞
マイクロサービスについて調べていくうちに共有DBはアンチパターンだそうで、機能単位で分割したらDBも分割することを知らなかったです。
それ故に、マイクロサービスのDBについてさらに調べることにしましたので、その勉強した結果を記事にしてみようと思いました。
＜今回勉強するにあたって参考にしたサイト＞
マイクロサービスアーキテクチャにおけるDB設計のパターン – Regardie's Salesforce Blog
※この記事のパターン1より共有DBがアンチパターンとの記述があります。
マイクロサービスをどう切り出すか ～マイクロサービスの凝集性・疎結合性を保つベストプラクティスと最適手法 - アイマガジン｜i Magazine｜IS magazine
※マイクロサービスが目指すべき状態の表より「データベースを介したマイクロサービス間の結合は避けること」との記述がありました。
これは他のマイクロサービスのDBに直接アクセスするのは良く無いという意だと思います。
＜結論＞
先に結論を書きます、DBは分けましょう。
何故ならば「機能単位では独立しているがDBを共有していると、どの機能群でDBのテーブルやカラムを使われているのかわからなくなってしまう」ということが起きてしまうからです。
後述で何故そんなことが起きてしまうのか？と私が想定したシナリオを交えて、記事を書いていきます。
＜何故そんなことが起きてしまうのか？＞
【今回使用するバックエンドの例】
例：掲示板アプリのバックエンド
__認証関連APIサーバー
上記、バックエンドの例より「認証関連APIサーバー」の開発チームがusersテーブルというのを製作していたとして、例えば「認証関連APIサーバー」チームが想定しない形でデータを更新される可能性あります。
具体的なシナリオとして以下を想定してみてください。
1、「認証関連APIサーバー」の開発チームがusersテーブルに向けてCRUD出来るという役割を持っていたとします。
2、「掲示板CRUD関連APIサーバー」の開発チームは掲示板テーブルに関連するCRUD出来る役割はあるが、usersテーブルに向けてデータの作成・更新・削除することは無いという役割だとします。(※参照は出来るとする)
「掲示板CRUD関連APIサーバー」の開発チームが掲示板に書込するユーザー情報を編集出来るようにしたら便利になるかな？と思いユーザー情報を更新するエンドポイントを制作した場合、共有DBだとDBにアクセスできてしまうのでusersテーブルの情報が更新できてしまいます。
上記のようなシナリオが仮に出てきてしまうと、認証関連APIサーバーチームは「どこかの機能郡から勝手にユーザーの情報を更新されている...」といった困った状態になるケースがあると思いました。
※機能単位でAPIサーバーを分割してるが、共有DBにした時にパッと浮かんだ想定されるシナリオを書いてみました。
以上、本記事の結論に対し「何故そんなことが起きてしまうのか？」という説明になります。
＜DBはどう扱うべきなのか？＞
DBを分割し他DBの情報が欲しくなった場合は、APIサーバー間で通信し取得した情報を利用する。
例えばユーザー情報をリクエストに含んで掲示板に書き込みをする時、本当にそのユーザーがDBに存在するのか掲示板のDB保存前に「掲示板CRUD関連APIサーバー」から「認証関連APIサーバー」に通信を行なって、ユーザー情報をチェックするという感じの運用をする感じですかね。
＜学んだ感想＞
マイクロサービスのDockerファイルを構築するときに、mysqlのコンテナ1つに対して、バックエンドのAPIコンテナを2つ立てる予定だったのですが、共有DBにするという手法はアンチパターンだと知りました。(※手を動かす前に知れて良かったです。)
しかし、DB分割により本来はDB1つだった場合は、左結合で済んでいた処理がマイクロサービス化すると他のデータベース上にテーブルが存在する、それ故にその情報を取得するためにAPIサーバー同士で通信し情報を取得してから自サーバーで任意の処理をするというような流れになったりすると思うので、最初の機能分けの段階で設計ミスするとかなり大変な思いをするなと感じました。
後から、〇〇APIと△△APIは分けない設計に変えます！って簡単に言えないと思いますし....
分割DBの設計について私の中ではこれがベストプラクティスです！って話せるように、もっと設計に関する勉強をして知見を深めていけるように頑張ります。
今回の記事は以上となります、次回記事でお会いしましょう。
マイクロサービスについて勉強してみた
＜何故この記事を書こうと思ったのか？＞
私はモノリシックなサービス開発ばかりしていて、マイクロサービスの良さがあまり理解できてませんでした...それ故に技術選定で後悔するような選択をしたくないので、これを機会に学びたいと思い記事を書こうと思いました。
後述のサイトを参考に勉強を進めました、サイトに書いてあるメリット・デメリットを閲覧し、私がパッと浮かんだ良さそうなところ・大変そうなところを書いてみたいと思います。
＜今回勉強するにあたって参考にしたサイト＞
マイクロサービスとは？メリットとデメリットを簡単解説 │ 株式会社NTTデータ イントラマート
マイクロサービスとは？代表的事例・メリット/デメリット・活用できるAzureサービスを一挙解説！｜SB C&S株式会社
上記サイトを見ると「マイクロサービスとは？」「モノリシックサービスとは？」情報がまとめられてます、もしもマイクロサービスとモノリシックサービスを知らない方は対象項目を見ないと、この記事は見づらいと思われます。
＜良さそうなところ＞
・負荷分散
これは、マイクロサービスなので機能単位でサーバーを分けれるから、負荷分散ができる点は良さそうだと思いました。
まずフロントとバックエンドのサーバーを分けれることができますよね。
他にも細かく分けるなら、バックエンドであれば機能単位で、APIサーバーが分けれますよね。(複雑な例を上げると長くなるので、簡単な例で書いてます。)
例：掲示板アプリのバックエンド
__認証関連APIサーバー
・異なる技術を採用できる
上記の例で出てきた掲示板アプリのバックエンドより、以下のようなことができますね。
仮に掲示板アプリのアサイン者が5名で以下のような配分であった場合のお話になります。
3名はLaravel未経験だがRuby on Rails経験あり
2名はRuby on Rails未経験だがLaravel経験あり
上記の場合は以下のような開発手法が取れそうですよね！
「認証関連APIサーバー」はRuby on Railsで開発(アサイン者：3名使用)
「掲示板CRUD関連APIサーバー」はLaravelで開発(アサイン者：2名使用)
※パッと浮かんだシナリオがこれでした、破綻してたら申し訳ありません。
＜大変そうなところ＞
・設計が大変
私がモノリシックなサービスばかり作っているせいか、実際に機能単位で分けるとしても、どう分けるのか？分けた後に疎結合することまで考えると、パッと良い設計が浮かばず...
(最初に機能単位で分割する設計からスタートすると思うのですが、分割単位を後から変える！というのは簡単にできないように思えますし、設計は大変そうに見えました。)
・統合テストが難しい
確かに機能単位で分けれる反面、統合テストでエラーが出た時に、別チームが制作した機能のAPIドキュメントがしっかり整理されていない場合に遭遇したとき、苦労しそうだなと思ってしまいました。
※以下は、私の勝手な想像になりますが....
APIドキュメントが古くて、なんかリクエストのパラメーターが不足してるんだけどそれが何だかわからない....といった風になると原因特定が大変そうですね。
＜学んだ感想＞
今回はメリット・デメリットが書いてある記事を閲覧し良さそうなところ・大変そうなところを簡単に書いてみました、「将来的に拡張が多そうだな」「規模が大きなサービスだな」と想定されるケースにはマイクロサービスを採用する価値はあるなと思えました。
今回の勉強を活かすために個人開発でフロントをNuxt.jsでバックエンドはLaravelを利用した開発にチャレンジをしてみたいと思ってます。
また、対象の開発にチャレンジしてみて開発に関する感想をブログの記事にしてみたいと思います。
以上となります、次回の記事で会いましょう。
Vscodeに向けてKarabinerを利用して自分の慣れたショートカットを設定して見る話
＜何故この記事を書こうと思ったのか？＞
みなさんってどんなIDE使ってますか？
私は仕事だとPhpStormを利用して開発を行なってますが、家のMacBookは有料IDEを使っていないので、Vscodeを利用しております。
Vscodeってファイル検索のショートカットなんですけど、「cmd」+「p」です....でも、PhpStormって「Shift」2回押すとファイル検索のショートカットキーなんですよね。
仕事の癖で「Shift」2回押しても「あれ？ファイル検索バーが出てこないぞ？」って個人開発中に何度もなってしまいました。
そこで、今回はPhpStormのファイル検索のショートカットキーをVscodeのショートカットキーに当てるよう！という案を思いつきました(天才)
※筆者もPhpStormに1133円を毎月払えるような人間に早くなりたいです(震え)
＜本記事のゴール＞
•Shiftを2回押すとファイル検索ができる。
＜作業の前提条件＞
•Karabiner-Elements
上記2つをインストールしていること。
そして、MacOsであること(※筆者宅にWindows端末もあるのですが検証に時間かかるので許してください。)
＜作業の流れ＞
•Karabiner側でキーマップ設定ファイルの編集
•KarabinerのGUIでキーマップファイルを有効化する
•Vscode動作テスト
＜作業開始＞
Karabiner側でキーマップ設定ファイルの編集
＜ターミナルで以下のコマンドを打つ＞
open ~/.config/karabiner
ここでFinderでKarabinerの設定ファイルが開きます。
※開かない場合はファイル階層が違うか、導入した先のディレクトリを参照してopenコマンド使っていきましょう。
＜Jsonファイルを作成＞
Finderで「complex_modifications」ファイル配下に好きな名前のJsonファイルを作成しましょう。
私はhoge.jsonにしました！(※後で何のショートカットかわからなくなるやつ)
Jsonに書く内容のサンプル写真は下記になります。
＜注意点＞
ファイル名称は適当でも、タイトルは分かりやすい名前にしましょう。
ここで適当な名前にすると、この後の作業や将来的にショートカットをたくさん登録したときに何のショートカットキーなのか思い出せなくなるからです。
＜KarabinerのGUIでキーマップファイルを有効化する＞
GUI上のComplex Modificationsメニューを開いて「Add rule」ボタンから今回追加したいショートカットを登録しましょう。
ここに今回追加した、ショートカットがあるので「Enable All」ボタンを選択し、ショートカット有効化が完了です。
＜Vscode動作テスト＞
実際にVscodeで左Shiftを2回押すと、ファイル検索が登場するようになりました！
※上記のように操作しても、ファイル検索が表示されない場合は「Karabiner側のJson」か「Vscodeの設定」を見直した方が良いかもしれません。
＜感想＞
無理して使ってる感もあるので普通にPhpStorm EAP版入れろよな！って感じの人もいると思いますがEAP期限終わったら、またVscodeに戻るのはめんどいので許してください。
そして、1回だけVscodeのショートカット設定で「Shift」2回って登録できないのかな？と思って操作してましたが、私はできなかったので有識者の方いたらコメントもらえると助かります。
Firebaseを使った爆速ログイン機能実装
＜何故この記事を書こうと思ったのか？＞
前回の記事はLaravel + Vue.jsを利用した記事を書きました。
しかし、今回はバックエンドがなくてもVue.js ＋ Firebaseを使うと(※プロジェクトに寄りますが)バックエンドの工数を大きく削減できるんだよ！ということを伝えたいと思い、記事を書こうと思いました。
＜前提条件＞
・HTMLとJSの基礎知識
・Firebaseのプロジェクト作成が済んでいる必要があります。
・Vue.jsの基礎的な知識(構文理解、ルーティング、メソッドの利用)
＜本記事のゴール＞
Firebaseを利用したログイン機能実装
＜作業の流れ＞
1、Firebaseのcdnの入手
2、Firebaseを利用するため必要設定埋め込み
3、新規会員&ログインフォーム作成
＜作業開始＞
1、Firebaseのcdnの入手
当時は以下のCDN使ってましたね(この記事では、h抜きのドメインだからCDN使う時に注意しましょう。)
ttps://www.gstatic.com/firebasejs/8.1.1/firebase-app.js
ttps://www.gstatic.com/firebasejs/8.1.1/firebase-analytics.js
2、Firebaseを利用するため必要設定埋め込み
一応、今回の記事ではログイン機能だけ設置するのでスクリプトタグにゴリゴリ書いちゃいましたが、コンフィグ関係の情報は環境変数に収めてユーザーの見えないところに、置くのが良いと思いますね。
※注：環境変数設定して、フロントのスクリプトタグに置く意ではないですよ笑
3、新規会員&ログインフォーム作成
ざっくりフォームHTMLとスクリプトタグのスクショ載せちゃいます。
＜新規会員画面＞
＜ログインフォーム＞
④新規会員登録&ログイン、ログアウトできるか検証
そして、Firebaseの管理画面を確認すると先ほど新規登録した「test@gmail.com」のアカウントが生成されているのを確認できました！
ログイン後のログアウトができるか検証し、無事ログアウトもできてますね！
＜後書き＞
Firebase Authenticationを使ったログイン機能実装はいかがだったでしょうか？
記事を執筆している私も、自分のアプリにログイン機能にて他プラットフォーム(Twitter,Facebook....等)アカウントからもログインできるようにしようと思ったらCreateメソッドのコードの中にif文を追加したりしないと行けないため、機能実装に時間がかかってしまうのでそういった問題を爆速で解決してくれるFirebaseがいかに便利かわかりますね。
それでは、失礼します。
