こんにちは!TECH Street編集部です!
今回は2021年9月7日(火)に開催した、 「AWSエンジニア勉強会 ~今おさえておきたいAWS最新トピックスとユーザーLT~」のイベントレポートお届けいたします。
今回はインフラエンジニアやクラウドエンジニアがおさえておきたい2021年上半期のトピックス情報そして最新情報をはじめAWS活用ユーザーによる事例LT発表をしていただきました。
登壇者はこちらのお三方!(登壇順に記載)
増田 健吾さん、宮本 太一さん/パーソルホールディングス株式会社
亀田 治伸さん/アマゾン ウェブ サービス ジャパン株式会社
それでは、早速ご紹介して行きます!
目指せプロキシ運用からの脱却!最近リリースされたネットワークFWを検証してみた
増田 健吾さん、宮本 太一さん/パーソルホールディングス株式会社
日系SIer、日系エンタメ企業、外資系コンサル企業を経て、パーソルグループのAWSクラウド基盤を運営するチームのマネジメントや基盤サービスのオーナー、クラウド戦略の考案などを担当している増田さん。そして、新卒でパーソルグループに入社し、増田さんのチームの一員としてPMを担当されている宮本さん。
今回は、フォワードプロキシにいくつか課題が存在していたため、マルチアカウント基盤で共通の出口を作り改善を図ることにチャレンジしましたが、結論としては構想していた構成は見送ることになったそうです。では、具体的になぜ見送る結論に至ったのかを紹介していきます!
現状と課題
まずは、パーソルのマルチアカウント基盤について。基本的には1アカウント1システムで構成するマルチアカウント基盤を採用。SharedアカウントにあるTransit Gatewayをハブとして、環境間でのプライベートアクセスを実現しています。
これまで各アカウント内にプロキシを設置していたため、下記2つの課題がありました。
①基盤内で同じ機能が重複する為コスト増大(構築・運用コスト、システム維持費用)
②フィルター運用が適切に行われないリスク
そこで、「共通のフォワードプロキシを作成し、基盤を運用するチームでこれを運用する」というソリューションを検討し始めました。
■As-Is
各アカウントの中にプロキシサーバーが1台以上稼働しており、構築と運用は各システムの開発・運用保守部隊が実施しています。
■To-Be
Security Accountのなかに共通のプロキシサーバーをたてたて、構築と運用は基盤の管理チームが実施します。このプロキシサーバーのざっくりとした要件は以下の通り。
・接続元:宛先ドメインのフィルター機能
・ドロップしたトラフィックのログ取得
・複数のシステムの通信に耐えうる拡張性・可用性
・基盤管理チームでも扱える程度のメンテナンス性
今回は、マネージドサービスの可用性とメンテナンス性に期待し、AWS Network Firewallの導入を検討しました。
To-Beの構成詳細は上記の通り。赤線が、外部(インターネット)へのアウトバウンド、青線が内部のクロスアカウントアクセス、緑線が外部(インターネット)からのインバウンドを示しています。
また、URLフィルターについてですが、AWS Network Firewallのファイアウォールポリシーは大きく2種類のルールグループで構成されており、上記の図にまとめています。
今回、全ての要件を満たすのはsuricataのみとなりましたが、suricataは設計可能な人が必要になる為難易度が高く、メンテナンス性の部分は△の評価となりました。
■使ってみてわかったこと(できること)
・システム側はEC2を立ち上げるだけでインターネットとセキュアに通信ができる
・意外とシンプルなルーティングになった
・ルーティングで全ての回線を持ってくる為、ガバナンス観点では最高
■使ってみてわかったこと(できないことと困りそうなこと)
・今回の構成では、システム担当者からすると通信経路が複雑で、結局システム側の開発スピードが下がってしまう
・通信経路が非対称になってしまう為、パブリックサブネットは少し困る
・接続元を絞ったURLフィルタリングはsuricataを1から書かないといけない為、優先度の設計などを含め基盤管理チームのスキルではハードルが高い…!
この結果として、構成は見送るという結論に。
今後は、ステートレスルールグループのdomein list形式に、接続元を指定する機能の追加や適用する制御ルールのグループ化と管理の機能の追加に期待したいとのことでした◎
今おさえておきたいAWS最新トピックス
亀田 治伸さん/アマゾン ウェブ サービス ジャパン株式会社
アマゾン ウェブ サービス ジャパンの亀田さんからは、「今押さえておきたいAWS最新トピックス」をご共有いただきました!
AWSのコンテナについて
まずは、AWSが提供しているコンテナのオファリングのおさらいから。コンピューティングリソースは年々抽象化が進んでいます。仮想マシンのEC2があり、その上にコンテナを配置するオーケストレーションサービス(ECS,EKS)が配置されています。次のフェーズとして、サーバーレスの要望が生まれ、結果としてLambdaやFargateというサービスも誕生してきました。
コントロールプレーンが、コンテナを良いかんじにサーバー上に配置してくれ、実際にコンテナが動作するのがデータプレーンとなっています。
コンテナの実行環境としては、先ほどご紹介したAWS Fargate、Amazon EC2を始め、AWS Local Zones、AWS Wavelength、AWS Outposts、EKS Anywhere、 ECS Anywhereなどがあげられます。
コンテナの実行環境が多様化するのと同時に、ネットワークも多様化していきます。例えば、Amazon VPC、AWS App Mesh、AWS Cloud Map、Elastic Load Balancingなど。
最新アップデート情報
■AWS Copilot
まず、2020年7月に、AWS Copilotがリリースされました。こちらは、AWSが開発したOSSのCLIツール。Amazon ECSでのコンテナアプリケーションの構築・リリース・運用・デプロイメントを容易にすることができ、インフラだけでなくアプリケーション開発に集中できるようになります。
従来、コンテナのシステムは普通のサーバーのシステムより、設定が大変でした。ロードバランサーの設定も必須で、ECS,EKSを設定しようとすると設定項目が多いことにうんざりしてしまったことがある方もいるのではないでしょうか。それを抽象化してくれるのがAWS Copilotです。
こちらは、宣言的マニフェストによって「アーキテクチャ」を定義しています。
マニフェストファイルとは、サービスの詳細をyamlファイルで定義したものであり、この設計図を元にAWS CopilotはCloudFormationテンプレートを作成してデプロイします。この、マニフェストファイルというものさえ作成しておけば、誰がいつマニフェストを実行してもおおよそ毎回同じような基盤が出来上がってくるというメリットがあります。
■ECS Exec
ECS Execは、AWS Systems Manager (SSM) Session Managerを使ってクライアントとターゲットのコンテナの間にセキュアなチャンネルを作成します。
ECSを使った場合と Copilotを使う場合とでexecする際の事前準備が異なることは注意が必要です。
■Bottlerocket AMI
Bottlerocket はコンテナを実行するために構築されたオープンソースの Linux ベースオペレーティングシステム。コンテナの実行に必要なソフトウェアのみが含まれており、SSH,Pythonなどのインタープリター、シェルは排除されています。SELinux Projectを活用して、Bottlerocket自体への変更も可能。/etcはブートごとに再生成されるメモリバックアップの一時ファイルシステムが搭載されています。
元々AWSが提供するコンテナは普通のLinuxで動いていましたが、コンテナベースで開発が進めていくと、不要なLinuxの機能も出てきます。最初から不要なLinux機能を持たないものを作ったのがBottlerocketです。
■ECS Anywhere
今年6月にはECS Anywhereというサービスもリリース。こちらはお客様が管理するオンプレミスのサーバーでコンテナを実行させるものです。
■AWS App Runner
コンテナ環境を実行させる基盤を作るのは結構大変ですよね。従来のコンテナの導入障壁を下げるために、2021年5月にAWS App Runnerというサービスもリリースされました。
■AWS App2Container(A2C)
また、AWS App2Container(A2C)へのアップデートも2021年7月に実行されました。AWS App2Containerは.NET及びJavaアプリケーションをコンテナ化されたアプリケーションに最新化するためのコマンドラインツール。コンテナ化するアプリケーションを選択するだけで、A2Cがアプリケーションアーティファクトと識別された依存関係をコンテナイメージにパッケージ化してネットワークポートを設定、ECSタスクとKubernetes pod定義を生成します。
2021年7月のアップデートでは、Windowsの複合多層アプリケーションのコンテナ化をサポートする機能が追加。個別にコンテナ化された多層アーキテクチャで動作するIISアプリケーションやWindowsサービスを、同一ホスト上で動作する複数のアプリケーションを単一のコンテナに入れてコンテナ化します。
■AWS X-Ray
通信及びアプリケーションパフォーマンスの監視も問題になってきます。一つのアプリケーションが複数のサービスから構成され、ログが別々に出てくるため、監視が従来の仕組みで提供できなくなっています。さらに、オンプレミス環境も監視しなければいけないため監視の仕組みはどんどん複雑化しています。そこで最近は、オブザーバビリティという概念がHOTなトピックスとして取り上げられています。
■Grafana
AWSでもオンプロミスのGrafanaをそのまま実行できるサービス(AMG)もつい先日リリースされました。
まとめ
どんどんアップデートが進んでいくAWSですが、より効率的に活用して業務の効率化も進めていければと思います!
ビデオオンの参加者の皆さまとの集合写真
ここからは、当日のQ&Aを紹介します♪
参加者から増田さん、宮本さんへの質問
“(Q)クラウドサービスが複数ありますが、どのサービスを選定するかお客様に説明するのに苦労しています。AWS利用がオススメとなるソリューションや業務モデルなどがありましたら伺えますとありがたいです。”
増田さん:持論になりますが、各社から沢山クラウドサービスが出ていますが、AWSがデファクトスタンダードだと思っていて、ナレッジの量が多いのが一番です。できることの差はあまりないと感じていますが、圧倒的なシェア率による事例があるところも嬉しいことや、誰かが通った道を通れるというところも"日本的な企業"としては有難いところです。
“(Q)「好きなサービス」AWSエンジニアなら定番だよね笑、今人気のサービスって何なんだろ?ずっと古いサービスばっか使ってるから、今流行り!これはオススメ!みたいなのを聞いてみたいです!”
増田さん:Network Firewallはオススメです。会社のニッチなセキュリティポリシーにより見送ることになりましたが(笑)
“(Q)セキュリティのポリシー厳しそう・・・”
増田さん:エンタープライズ企業ならではかもしれないですが、セキュリティポリシーにあらがって、自走をしていきたいとは思っています。
“(Q)NAT Gatewayってプロキシとして使えないんでしょうか?”
宮本さん:プロキシという意味だと使えます。自社のセキュリティ要件で見送りとなりました。URLフィルタリングなど、賄えない部分があったので…
“(Q)アカウントとはVPCを指しているのでしょうか。”
宮本さん:今回は使わない構成にしているので、異なるものと思っていただければと思います。
“(Q)ToBeいいですね。こういうのは現場で策定してスマートに実現できる感じですか?”
増田さん:チームの体制としてはスクラムを採用しているので、やりたいと思ったら自由にできる制度にはなっていますが社内のポリシーに振り回される部分もあります。
“(Q)色々情報部門からの制限や制約が多いのですが、パーソルさんはどのように戦っていますか?”
増田さん:ときには、喧嘩(笑)することもあります。何故それをやるのか?上流に立ち返ることをしています。また、代案を出しつつ、対策しています。
宮本さん:セキュリティ要件は何だっけ?防ぎたい事項は何だっけ?を大切にコミュニケーションしています。
“(Q)基礎的な質問でしたらすみません。 先ほどの設計で、機能別にアカウント(VPC)を作成されていましたが、これは一般的によくある設計なのでしょうか。”
増田さん:VPCではなく、アカウントという前提でお話させていただいており、アカウント毎で管理していく概念「マルチアカウント構成」を採用しています。最近では、この概念が浸透してきていると思います!
参加者から亀田さんへの質問
“(Q)所属先の兼ね合いというか何というかで、Backup Audit Manager気になってます。”
亀田さん:8月にリリースされた機能で、バックアップのログをオーディット用に管理する機能です。ぜひ、機能をオンにして試してみてください。
“(Q)運用手順の改修と費用の問題でなかなかコンテナ化に辿り着けないのですが、こういうのってウチだけでしょうか?”
亀田さん:コンテナはDevOpsと似ていて、システムというよりはカルチャーです。組織的に分離しているところだと、必要性は認識されづらい。アプリ側は便利だけど、運用側はめんどくさいかもしれません…。
運用と開発が分かれていれば、運用チームとしてはメリットを感じづらいと思います。
“(Q)従来のコンテナの作り方では出来た設定が、App Runnerでは出来ないところはありますか?”
亀田さん:現時点では、VPCの中身に入れないのが課題で、Auroraなどに入れません。ここが最大の注意点ですが、改修予定はあります。
“(Q)コンテナについてはコンテナセキュリティをどのようにすればよいのか悩んでいます。 ざっくりした質問で恐縮ですが、コンテナセキュリティのトレンドは昨今どのようになってますか? ベストプラクティスを知りたい!”
亀田さん:まず、セキュリティについて話をする際は、データセキュリティなのかネットワークセキュリティのどちらの話なのかを確認してから話しています。データセキュリティだとすると、コンテナは基本イミュータブルであるべきという大原則があるので、コンテナの中に個人情報を蓄積していくのはバッドプラクティスです。AWSが提供しているECRはイメージスキャンの機能がデフォルトでついていますので、こちらもぜひ試してみてください。
“(Q)亀田さんからしてエンタープライズ企業でコンテナが導入しづらい要因って何だと思いますか?”
亀田さん:カルチャーだと思っています。ネットワークのチーム、インフラチーム、Javaチーム、のようにチームを分けているとメリットが感じづらいと思います。大企業はすでに大きな収益を持っているため、大きくそのシステムを変える必要はありません。しかし小さいところだと陰りがでてきたら、大きく体制を変える必要があり、コンテナを導入することになったりする。
DevOpsだと、作った人が前提になるので、設計思想まで伝わらず使いづらいものになってしまう。SIモデルが日本全体の遅れを引き起こしているとよく言われていますので、海外と比べて遅いのはこういう理由に起因しているのかもしれません。
イベントレポートは以上です◎今後のイベントもお楽しみに!