はじめに
私は2024年1月からAWS設計構築のプロジェクトに入り、現在設計を進めている真っ只中なのですが、プロジェクトにアサインされてからの気づきについて書き留めてきたいと思いましたので本記事を執筆いたします。
まず、結論ファーストでお話させていただきますが、タイトルの「AWSエンジニアにとって必要な知識」についてはIT全般の知識を7割程度把握 しておくのが自分的ベストプラクティスかと思います。
ある知識に特化しているよりも、全体的に網羅されている方がことAWSにとっては必要な要素ではないかと考えています。
なぜなら、設計において任されるタスクは自分の得意としていない分野においても任されるからです。
ではその全体の知識って具体的にどんなことを知っておいたら良いの？について紹介していきます。
Linuxの知識
言わずもがな、Linuxの知識は必須になってきます。
前提として設計段階でEC2を使って検証したいといった場合に、Linuxのコマンドが使えないと話になりません。Linuxコマンドを全部は知らなくても、基本的なコマンドは頭の中で把握しておく必要があります。
これなんだっけ？は調べれば良いです。
私はLinuC-1の資格学習をする上でNotionにLinuxコマンドチートシートとしてコマンド表を作成しました。
vi
Linuxコマンドは最低限という話をしましたが、viについても同様です。
Linuxを使用するからには必ず何かしらのファイルをいじります。
その際にviを使ってファイルの中身を編集することになりますので必須です。
こちらについてもviコマンドのチートシートを作成して、忘れてしまった場合にすぐに辞書代わりとして引けるように作成しております。
上記の内容は最低限必要な知識となってきますので、Linuxにあまり詳しくないという方は学習しておくと良いでしょう。
おすすめの本
このシリーズの本漫画と思って侮るなかれ。
文字だけでは取っつきづらい方には読みやすいし、ちゃんとLinuxのことをわかりやすく解説しているのでおすすめです。
余談ですが、
本プロジェクトで私はLinuxOSの設計自体のタスクを実施してはいないのですが、LinuxOSの設計をするとなった場合、Linuxコマンドだけでなくさらに深い知識が必要になるでしょう。(私もLinuC-2以上の知識は随時調べないとわからないレベルです)
ネットワークの知識
Q. ネットワークってネットワークエンジニアの仕事じゃないの？
A. ネットワークエンジニアだけの仕事ではありません。
AWSの設計においては必ずネットワークの設計は付き物です。
どことどこの通信は通しますよ、ここからの通信は拒否しますよ、を考えてルートの設計をしなければいけません。
結構これが厄介で、最初の段階で全てのルートを網羅して完璧に設計しきるのは正直不可能だと思っています。
が、各サービスの設計をする段階で、当たりがあるなら都度フィードバックをして設計修正していく必要があるかと思っています。
AWSのサービスは以下のサービスが該当します。
- Amazon Virtual Private Cloud(VPC)
- セキュリティグループ、ネットワークACL
また、オンプレのネットワークを専門にしている人は必ずハブを使用するかと思いますが、ハブの役割を担う
AWS Transit Gatewayといったサービスもございます。
Transit Gatewayはオンプレ ⇆ AWS間、異なるAWSアカウント間の通信をする際に非常に有効なサービスとなります。
その他にはVPN = Virtual Private Network 仮想専用線です。
余談ですが私は略称は必ず略さない名称が何かを確認し、かつその日本語訳は何かを調べます。
なぜなら、そうすることで言葉の意味を理解できるからです。
そんなの当たり前だろ、と思うかもしれませんが、「コレはそういうもの」という覚え方をされている方もいるかと思いますので、必ず略語は訳し、日本語の意味を調べましょう。
話を戻します。
VPNについてはオンプレ環境からAWS環境に繋ぐ要件が存在することがあります。
その際に必要になるのがInternet上でデータ通信する際に通信経路を暗号化すくことでセキュリティを担保できます。
VPNについての主なAWSサービスは以下のようなものが該当します。
- AWS Site-to-Site VPN
- Client VPN
DNSの知識
DNS = Domain Name Systemのことですね。
ドメイン、いわゆるexample.comのようなリンクでブラウザにアクセスしたら、サーバーが対応するIPアドレスを特定し、example.comのWeb画面を返してくれる仕組みですね。
AWSの場合はAmazon Route53というサービスを使用することでDNSの名前解決を行います。
要するにDNSの仕組みを理解していないとRoute53の理解もできないということです。
以下の本はDNSの仕組みを事細かに解説している良書ですので、ぜひ手に取って学習されることをオススメします。
セキュリティの知識
セキュリティについて苦手意識をもってるかた多いのではないでしょうか?
セキュリティ難しいですよね。
TLS、共通鍵暗号方式、公開鍵暗号方式、ファイアフォール、ここら辺の内容を理解しておく必要があります。
暗号鍵について
暗号鍵に関してはAWSでマネージドしてくれるサービス (AWS Key Management Service)がありますが、例えばS3バケットへデータを保存する際にKMSのカスタマーマネージドキーを使って開発者がキーの管理を行うといった要件などもあります。
その際のキーの暗号化方式をどうするか？といった際に共通鍵暗号方式、公開鍵暗号方式の仕組みを理解しておかないと設計できません。
WAF、FWについて
WAFやFW(Firewall)についても当然要件として存在します。
インターネット外部からAWS内にトラフィックを受ける際に、SQLインジェクション、XSS、DDOS攻撃といったものを対策することや、特定のIPのみにトラフィックを制御する、といった対策をすることでセキュリティを担保する狙いがあります。
AWSではAWS WAFやAWS Network Firewallといったサービスを使用することで上記のセキュリティ対策を行うことが可能です。
TLS証明書について
TLSプロトコルによってHTTPを暗号化したHTTPS通信を実現するためにはTLS証明書が必要になりますが、そのサービスがAWS Certificate Manager(ACM)です。
これはAWS側でTLS証明書を作成、更新、管理をしてくれるマネージドサービスですが、鍵の暗号化の仕組みついては理解しておく必要があるかと思います。
インターネットの通信プロトコルでは、通信している相手が自分の思った通りの相手なのか、悪意を持った相手なのかを判断する術がありません。
そこで登場するのはTLSの仕組みで、要するに交通手形のようなものを作成し、第三者機関に認められた交通手形を持っている人のみ道を通しますよ、といった仕組みです。
これらを細かく学習できる本が以下です。
本書ではTLSの仕組みをハンズオンで解説してくれる本なので、座学だけではなく手を動かしながらイメージを掴みやすくなっています。
こういった本は座学形式の本がメインの印象でしたが、ハンズオンを交えて学べるのは非常に貴重かと思います。
Dockerの知識
最近はコンテナの技術はほぼ必須になってきました。
アプリケーションが動く環境はコンテナを使って、コンテナが死んだら自動再作成というサイクルをすることで運用コストをかけない設計が主流になってます。
Dockerとは何か?
Dockerのコマンドの意味
これらを理解しておく必要があります。
Dockerを理解するには最低限Linuxのコマンドを理解しておかないとハードルが高くなりますが、逆に言うとLinuxコマンドを理解しておけばDockerの学習ハードルはぐんと下がります。
Dockerコマンドを使用してやることはだいたい限られていますので、ここは頑張って理解しておきたいところです。
それ以外にはDockerfileの書き方やその意味。
DockerfileはいわゆるIaCで、コンテナ環境をコードで管理するドキュメントです。
このDockerfileがあることで、いつでも同じ環境のコンテナを作成することが可能です。
Dockerの基礎を学ぶためにおすすめの本は以下です。
そもそもDockerとは何か？というところから、Dockerのレイヤーの話、Dockerコマンドなどが絵付きで事細かに解説されています。
私は今まで理解できていなかった内容がこれ一冊で基礎は学べたと思っています。
Dockerについて理解できている方は一歩進んでKubernetesを学習すると良いかと思います。
KubernetesについてはKubernetesってそもそも何？という記事を以前Qiitaの方で執筆したことがありますので興味ある方は読んでみてください。
Kubernetesとはコンテナオーケストレーションツールの1つですが、複数のノードによってクラスタを構築し、そのクラスタ内でコンテナの立ち上げを行います。
そのノードの中で実行するコンテナの運用管理を自動化することで運用コストを削減できるツールです。
マニフェストファイルというyaml形式のファイルを用いることで、各種リソースの定義を行いことができます。
Kubernetesのメリットは以下のようなものがあげられます。
- コンテナのデプロイを自動化
- 高負荷時にはマニフェストに応じたコンテナ数をスケーリング
- 死活監視の自動化
- 障害発生時のセルフヒーリング (コンテナの自動復旧)
- 宣言的コードによるIaC化
Kubernetesのデメリットは以下です。
- 学習コストが高い -> 最初は何を言っているのかさっぱりわかりません。Dockerをある程度理解していたとしてもKubernetesの概念が異なるため、Kubernetesってそもそも何なの？を理解するまでに時間を要します。当然マニフェストファイルに何が書かれているのかを理解する必要もあります。
- アップデートが多い -> 平均して4カ月に1度の頻度でKubernetesのマイナーバージョンをリリースしています。
※ちなみにKubernetesについては私も学習中です。
IaCの知識
Q. AWSはインフラの分野だからコードは書かないと思ってないですか？
A. そんなことはありません。コードは書きます。
AWSのリソースはIaC化されるのが主流となっていますので、CloudFormationやTerraformなどでAWSリソースのコード化を行い管理することになります。
CloudFormationとはAWS純正のIaCツールです。
TerraformはHashiCorp社が開発しているインフラ構成管理ツールで、HCL(HachiCorp Configuration Language)という言語で記述されています。
どちらを使うかは現場によって異なるかと思いますが、SIer系の企業の場合にはOSSツールの使用はあまり好まれないため、AWS純正のCloudFormationを使用する企業が多いのではないでしょうか。
逆に自社開発系の場合はTerraformを使用する傾向が多いイメージです。
おそらくこの違いは、SIer系企業はより信頼性の高いものを使用して担保しようとする傾向にあるため、OSSよりも純正のものや商用のものを第一選択肢としているためかと思います。
逆に自社開発系企業ではより利便性の高いものを第一選択肢とするため、特に躊躇せずOSSツールを使用するのだと思います(これは筆者の感想です)
少し話はそれましたが、CloudFormationとTerraformの違いについては、以前一部自身で執筆したKindle本の内容を抜粋してお伝えします。
| 項目 | CloudFormation | Terraform |
|---|---|---|
| 設定ファイル | YAML/JSON | HCL (HashiCorp Configuration Language) |
| ファイル形式 | .yml/.json | .tf |
| 事前準備 | テンプレートファイルが必要 | - Terraformのセットアップが必要 - aws cliのインストールが必要 |
| リソースの作成/変更/削除 | AWSマネジメントコンソールやAWS CLIを使用してスタックの作成/変更/削除を行う | Terraform CLIを使用してリソースの作成/変更/削除を行う |
| 差分検出 | ドリフト検出という機能で検出する | Planコマンドを実行してtfstateを比較して差分を検出する |
| メリット | ymlやjsonなどのテンプレートファイルがあればコンソール上から簡単に操作ができるので導入ハードルが低い | - プログラミング言語に近い記述なのでプログラミング経験者はなじみやすい - AWS以外にもGoogle CloudやAzureといったプロバイダーに対応している |
上記の内容は以下Kindle本の中身を一部引用しています。
CloudFormationやTerraform以外にも、例えばPythonを使って処理をすることなども考えられます。
AWSにはAWS Lambdaといったサービスがありますが、Lambdaはサーバーレスでコードを実行できるサービスです。
Lambdaの使いどころは、例えば、
- S3バケット[1]に画像がアップロードされたときに、S3のイベントをトリガーとしてLambda関数を自動的に呼び出し、画像のメタデータの取得し、取得したメタデータをAmazon DynamoDB[2]に保存する。
このLambdaはNode.js, Python, Java, Ruby, C#, Go, PowerShellといった言語がサポートされています。
どの言語を使ってLambdaを使用するかは現場によって異なるかと思いますが、その中でもPythonは人気が高く、多く選ばれるのではないでしょうか。
選ばれる理由としては以下の観点かと思います。
- 起動時間の速さ: 特に小さなスクリプトの場合、起動時間が短く、レスポンスタイムが優れているため、Lambdaの短時間の実行に適している。
- シンプルなコード構造: 比較的シンプルで短く、Lambdaのような関数単位の処理と親和性がある。
- 幅広いライブラリの利用: Pythonはデータ処理、機械学習、APIハンドリングなど、さまざまな用途に対応できる豊富なライブラリを持っており、サーバーレス環境でも強力である。
こういったサービスもあることからAWSエンジニアはコードを書く必要があるのですが、本職のプログラマーほどのプログラミング能力は必要ないですが、プログラミングの概念を理解しておく必要があります。
最後に
本記事ではAWSエンジニアに必要な知識についてまとめてみました。
この記事内にまとめた内容はほんの一部であり、完璧にすべての内容が網羅できているわけではありません。
ちなみに私はこんなの細かく理解してる必要はない、という意見には反対です。
仕組みを理解して言語化できるまではエンジニアの仕事だと思っています。
もちろん全てを完璧に理解するのは不可能なので、都度出てきたら学ぶという姿勢で良いかと思いますが、なんとなくこうだから、という理由ではエンジニアの世界では通用しないと思っています。
私もまだまだITの根本的な部分を理解できていないことがたくさんありますが、このITの根本の部分を理解することで、今後新しい技術や自分が使ったことない技術に遭遇したとしてもキャッチアップする速度に違いが出てくるかと思います。
これからAWSエンジニアを目指そうと思っている人に対して少しでも役に立てば幸いです。
Discussion