本投稿は TECOTEC Advent Calendar 2022 の8日目の記事です。
こんにちはSREの譚です。インフラの設計、保守、運用が主な仕事で、インフラの知識は多いですが、開発経験もあります(vue、bash、python)。
インフラ関連知識は開発にも役に立つことをみんなに知っていただきたく、今回はSREの視点からエンジニアが知っておくべき知識を語りたいと思います。
自分の知識量はどれくらいあるかチェックしましょう。
Linux
Linuxは基本中の基本です。完全マスターとは言わないが、せめて下記の知識を覚えていただきたいです。
よく使うコマンド
- cd
- ls
- echo
- cat
- netstat
- ps
- mv
- cp
上記はごく一部のコマンドで、よく使うコマンドはおよそ20個くらいです。知っておけば、簡単なbashでも書けますし、デプロイしたソースが起動しているかどうかもすぐ確認できます。
ファイルの権限
間違ったファイル権限設定はデプロイしたソースの動作に影響します。ネットで記事を拾って、権限を777に設定するのは権限理解していないケースです。
勉強ポイント
- r,w,x権限の基本意味
- ファイルとディレクトリのr,w,x権限の違い
- owner、group、otherの権限
作業ディレクトリ
Linuxにおける誰がどこに何をするのが大事で、作業ディレクトリという概念は頭に入れておきましょう。
勉強ポイント
- pwd - 現在の作業ディレクトリを確認する
- id - 現在使用しているユーザーを確認する
ネットワーク
現代開発ではネットワークは重要で、関連知識があればエラーとか一発解決できます。
プロトコル
ここでよく使っているプロトコルを挙げます。分からないプロトコルがあったら調べてみてください。
プロトコルとは、コンピュータでデータをやりとりするために定められた手順や規約、信号の電気的規則、通信における送受信の手順などを定めた規格を意味します。一言でいうと送信側と受信側が協議した通信方法です。
身近なものとして、インターネット接続に用いるTCP/IPや、Web閲覧などに用いるHTTP、メール送受信に用いるPOPやSMTPなどが挙げられます。
プロトコルの種類が多く、全部覚えるのは無理でしょう。下記のプロトコルとその用途やポートだけ覚えるだけでも仕事に役に立ちます。
勉強ポイント
- TCP&UDP - 区別と用途
- DNS - 用途、ポート、レコードの記述方式
- HTTP&HTTPS - 使用しているport
- DHCP - 用途
- WebSocket - 用途
- ICMP - 用途
ロードバランシング
ロードバランシング、いわゆる負荷分散です。本番には考えないといけない項目です。特にスティッキーセッションが必要かどうかはプロジェクト要件に応じて考えてください。
勉強ポイント
- ロードバランサーの機能と仕組み
- ロードバランシングの種類
- スティッキーセッション
CDN
CDNを利用することによってアプリやウェブページのレスポンスタイムを短縮することが可能ですが、その前にCDNの仕組みと機能をきちんと勉強しましょう。勉強せず使うとレスポンスタイム短縮できずに費用も爆上がりになりかねません。
勉強ポイント
- CDNの仕組み
- CDNの機能
- CDN費用抑える方法
NAT
NATはIPv4のIPが足りない問題を緩和するため誕生した技術です。
NATを使えばサーバーがパブリックIPつけなくてもインターネットにアクセスできます。
ここで問題: ドメインのIPはロードバランサーのIPなのか、それともNATのIPなのか?
勉強ポイント
- 仕組みと用途
ミドルウェア
よく使われるのはNginxとApacheです。ウェブサーバーの門番とも言えるでしょう。
勉強ポイント
- Nginx&Apache 用途と役割
フレームワーク
フレームワークはバックエンドとフロントエンドがあります。
ソースのメンテ観点からみて本番にはバックエンドとフロントエンド分けることをオススメします。
- バックエンド - 主にデータの処理、APIのルーティング
- Laravel(PHP)
- Django(Python)
- Rails(Ruby)
- express(Node.js)
- フロントエンド - 主にデータの表示、UIの作成
- Nuxt(vue)
- Next(react)
- フロントエンドとバックエンド一緒
- Laravel
- Django
CI/CD
開発段階から設定すべきものです。いかに正しく自動的にデプロイするのが大事です。
- Jenkins
- CircleCI
- AWS CodePipeline
最後
- 開発段階で本番のように設定したら開発効率が悪い
- 台数が少ないから手動でやればいいので
- なぜローカルテストは問題ないのにデプロイしたらエラーだらけだろう
- なぜパフォーマンスが悪いだろう
そういう質問を抱いているエンジニアは少なくないでしょう。
自分の経験から言うと開発設計段階でフロントエンドからバックエンド、DBまで何もかも数百万ユーザーの規模で設計してください。
数百万ユーザーの規模になるとサーバー台数は100台以上、DBのレコードも何百万件以上になり、ソース中のfunctionのパフォーマンス、DBの接続数のコントロール、SQLのパフォーマンス、データの分割、cacheの使うところ、機能ごとの処理能力、micro service化、serverless化、デプロイの仕方などなど考える必要になってきます。
こうすることでだんだん質の高いプログラムが書けるようになり、上記の知識も知らないうちに身につけます。