AWS豆本制作秘話~その3 手動のメリットは何もない！
こんにちは！AWS認定インストラクターの山下光洋です。
2024年6月20日のAWS Summit Japan 2024で、弊社はAWS Training Partnerとして参加をしてきました。
会場では、100部限定で制作した"AWS豆本"を配布し、大好評！！
ブログでは、その豆本の制作秘話を全7回に渡ってお届けします。
今回は、その3を伝えたいと思ったエピソードと関連サービスです。
その1 迷ったらWell-Architectedな選択肢を選ぶべし！はこちらよりご確認ください。
その2 AWSの気持ちになって考えるべし！はこちらよりご確認ください。
目次[非表示]
AWS豆本とは
AWS豆本とは、弊社が制作したAWS認定試験の受験に役立つ7カ条をまとめたミニブックの総称です。
豆本とは、掌に収まる程度の小さな本の総称である。
引用：ピクシブ百科事典
ということで、掌(手のひら)サイズにぎゅっと必要な情報が集約されています。
実際に制作したAWS豆本がこちら↓
弊社のAWS認定インストラクターが、豪華に表紙(右)も裏表紙(左)も飾っています。
表紙(右 グリーン)：左より髙山、山下
裏表紙(左 白×ピンク)：左上より、小池、金井、海老原、難波、三浦
それでは、以下より当日豆本と一緒にお配りしましたカードと7カ条の制作秘話をご覧ください。
なお、今回の豆本のきっかけは、こちらのその1 迷ったらWell-Architectedな選択肢を選ぶべし！で更に詳しくご紹介しています。ぜひご覧ください。
その3 手動のメリットは何もない！
それではAWS認定試験の7カ条を1つずつ背景や意図などを説明します。
その3である今回は「手動のメリットは何もない」です。
AWSの仕組み
AWSのサービスにはすべてAPIエンドポイントがあり、APIリクエストによって操作ができます。
例えば、APIがない状態で考えてみます。
開発者はこんなサーバーがほしいというリクエストをパラメータシートなどに入力して、メールやワークフローシステムでインフラ部門に送信します。
それを受けたインフラ部門はその開発者がサーバーをリクエストできる人か、承認はされているかなどを確認してOKであれば、サーバーを調達したりイメージからOSをインストールしてパラメータシートどおりに設定して、物理ラックの中で起動したサーバーのネットワークなどを設定してアクセスできる状態にして、開発者に完了とアクセス先などを連絡します。
このやり方では構築に時間がかかりますし、インフラ部門がミスをしてしまうこともあるかもしれません。
AWSはこのやり取りを自動化しています。
APIエンドポイントを用意してリクエストを受取、この人が起動をできる人かどうかIAMの認証認可の仕組みで判断します。リクエストが許可されたタイミングで設定値も決まっていますので、開発者には受け取った旨と必要な情報をレスポンスします。
仮想サーバーの構築や設定はInfrastructure as Codeにより自動化し、完了すればアクセスができます。
全世界にあるリージョンごとにAPIエンドポイントがあります。
直接APIリクエストを実行することもできますが、認証情報の署名や一時的なリクエスト拒否時の再実行などを考慮、処理しないといけないこともいくつかあります。
それらをもっと簡単に実行できるようにしているのが、マネジメントコンソールや、CLI(コマンドラインインターフェース、Linux シェルコマンド/Windows Powershellコマンドなど)、SDK(ソフトウェアデベロップメントキット、Python, Javaなどさまざまな言語向けに簡単に開発できるように用意されたライブラリなど)です。
AWSはこのSDKなどを利用したエージェントを提供していたり、サービスが内部的にほかのサービスAPIを呼び出して自動化しています。
この自動化の仕組みが利用できる場合は積極的に利用した方が、私たちの手作業による運用負荷が減り、セキュリティ実装、パフォーマンス向上、運用の改善、コスト最適化、可用性の向上、ビジネスに直結するアプリケーションの開発などよりやるべき仕事に集中できます。
そのようなもう既に用意されている自動化の例を紹介します。
AWS CloudFormation
CloudFormationは次のようなテンプレートにVPCやEC2などAWSリソースの設定をあらかじめ書いておきます。
次のテンプレートは例で省略してますのでこのままでは動きませんが、書き方として参照してください。
Resources:
VPC:
Type: AWS::EC2::VPC
Properties:
CidrBlock: 172.31.0.0/16
EC2Instance:
Type: AWS::EC2::Instance
Properties:
Tenancy: default
SubnetId: !Ref PublicSubnet1
SecurityGroupIds:
- !Ref EC2SecurityGroup
ImageId: !Ref AmazonLinuxAMIID
InstanceType: t3.micro
このようなテンプレートをYAMLまたはJSONでテキストファイルに記述して、CloudFormationのスタック作成時に指定します。
そうすると書かれたとおりにリソースが作成されます。
一度テンプレートを作っておくと、何度でも同じスタックが作成できますので、本番環境、開発環境、テスト環境で設定に差異が生じたり、設定ミスをすることもありません。
マネジメントコンソールで手動設定するよりもすばやく環境を構築できます。
私は研修などで50アカウントに同じ環境を10分ほどで作成するためにCloudFormation StackSetsという機能を使用したり、仕事で使っている一時的に必要なツールを再構築するために使用したり、同じような設計を何度も構築するときに使用したりして、効率化しつつ正確に作業しています。
Amazon CloudWatch Logs
EC2にインストールしたOSやソフトウェアのログを収集して分析したいとします。
サードパーティと呼ばれるAWS以外のログ分析ソフトウェアをEC2インスタンスなどにインストールして、そこにログを送信するための仕組みを作って収集するということももちろんできますが、その場合ログ分析ソフトウェアのためにOSやソフトウェアへのパッチ適用やインスタンス障害時の復旧などの運用が発生します。
1つの選択肢としてCloudWatch Logsという機能があります。
CloudWatchというマネージドサービスの機能で、ログを収集して検索、クエリー分析、文字列フィルタによるアラームや自動データ連携、連携先のAmazon SNS(Simple Notification Service)からの通知や追加処理の自動化など、さまざまな機能を持っています。
マネージドサービスというのは私たちがOSを管理することなくAWSに管理を任せられるサービスです。その範囲はサービスによって異なります。
CloudWatchの場合は、ハードウェア、データセンター、OSなどを私たちが運用する必要なく、複数のアベイラビリティゾーンという離れたデータセンターに配置されているのでデータセンターレベルの可用性も私たちが構成しません。
CloudWatch LogsのAPIエンドポイントにPutLogEventsアクションを実行してログを収集できます。
このPutLogEventsアクションが実装済みでAWSが提供しているのが、CloudWatchエージェントです。
CloudWatchエージェントはEC2インスタンス、オンプレミスサーバーにインストールして使用できます。
こうすればログ分析サーバーの管理をすることなく、ログ送信のためのプログラムも開発することなく、ログ収集と分析、モニタリングを素早くはじめられます。
AWS ConfigルールとSystems Manager Automation
AWSの運用や管理をしていて、会社のルールとしてやってほしくないリソース設定がされたときにそれを発見して、修正しないといけません。
それを自動化できるのが、AWS ConfigルールとSystems Manager(SSM) Automationの組み合わせです。
ConfigはAWSリソースの設定情報を記録します。
設定変更が発生した際も履歴を追加記録していきます。
Configルールを設定すると、ルール違反したリソースをすぐに発見できます。
例えば、セキュリティグループのSSH 22番ポートをインバウンドで許可してはいけないというルールがあったときに、誰かがその設定をしたことを検知できます。
Configルールは任意で構築することもできますが、AWS管理ルールとしてあらかじめよくあるケースが用意されています。
前述のSSHルールもすでに用意されているので選択するだけで使用できます。
検知した際にSNSで通知することもできます。
さらにSSM Automationという機能を使って自動処理ができます。
SSM AutomationはAWSのリソース設定などAPI処理を自動化できます。
任意でAutomationランブックという実行する内容を構築もできますが、AWSがすでに用意しているランブックも選択できてすぐに使用できます。
セキュリティグループから無制限のSSH受信ルールを削除するランブックもあります。
Systems Managerランブックリファレンス AWS-DisableIncomingSSHOnPort22
これで誰かがやってはいけない無制限SSH受信ルールを作成した際に自動でルール削除までできます。
便利な自動化機能が選択できるときは、積極的に検証して利用しましょう。
「手動のメリットは何もない」を伝えたかった理由
今回豆本をやろうとした際に、せっかくだから7カ条にしようと思い、書き出してみました。
そこでこの「手動のメリットは何もない」が出てきたときは、少し悩みました。
「何もない」は言い過ぎではないだろうか、手動作業を主にされている方々はいやな気持ちにならないだろうか、などを考えました。
本当のタイトルは「手動のメリットは何もない、もしかしたらあるかもしれないけど自動化にトライしてみないとわからない」かもしれません。
でも、そのような長いタイトルよりも短く言い切ったほうが目に止めていただきやすいと思いました。
結果、このタイトルに共感したり気に入ってくれた方が一番多かったように思います。
ここまで極論めいたことを言いたかったことには理由が2つあります。
1つは私の原体験で自動化は私と仲間を助けてくれて、手動作業はミスと残業をもたらしたことです。
もう1つは自動化しない原因に、良くしようという思いよりも変化を嫌う性質があったことです。
自動化は私と仲間を助けてくれた
手動作業のデメリットは大きく2つです。
- 時間がかかる。
- ミスがおこる。
この2点に私自身も同じ会社で働く仲間も苦しめられていました。
残業を伴う長時間労働や休日出勤が発生したり、ミスによって泣きながら謝っている人もいました。
これらは自動化するだけで解消されます。
会社の仕事には、会社に入ってくるインプットデータを処理してアウトプットにするものが多くあります。
この処理の中でサービス提供などが行われて、請求書やレポート、会計データや外部連携データとしてアウトプットされて1つの仕事が完了します。
インプットデータは例えば飲食店であれば伝票データや勤怠データ、ホテルであれば予約データと現地の注文データ、製造であれば発注データ、図面データなど、多岐にわたりますがどこかのタイミングでデータになります。
最初からデータとして連携されるものもあります。
なのに、そのデータを手動で扱い、時間をかけミスが発生してしまい、涙を流しながら仕事をしている現場を何社も目の当たりにしてきて、私の前職までのITとしての仕事はとにかく自動化だと考えていました。
まずは今行われている手動のデータの処理を自分の仕事として引き取って、処理内容を知ってから自動化します。
自分の仕事を自動化しているだけなので素早く正しくできます。
このプロセスを繰り返して、担当部門の休日出勤をなくしたり、残業負荷にかかるような作業をなくしたり、ミスをなくしたり、時には不正ができない状態にしたりしました。
自動化しない原因は立場を守っているだけだった
このような仕事のやり方をしていると妨害にあうことも多くありました。
他部門の仕事を自部門に持ってくることを部門の管理職が嫌がります。
「他部門がミスをしても自分たちの責任ではないが、自動化してミスが起こったら我々の責任になる。」
こんなことを平気で言う人もいました。
いったいどこ向いて仕事したらこんな思考になるのかまったく理解できませんでした。
自分の立場を守ることしか考えていない、こんな人と仕事するぐらいならいつ辞めても構わないと思ってました。
なので、前述のように勝手に自分の仕事にして1~2ヶ月手動でやってみて正しい処理を知って、自動化していきました。
中には自動化できるシステムでも「一度そのままCSV出力してアップロードを手作業で〇〇部にやってもらおう。そうすれば最終チェックはあっちの責務になる。」
こんな仕組みの作り方を日常的にやってる人もいました。
世の中には残念ながらこういう人たちはいますし、立場をうまく守って見せていてその役割にしがみつき、改善しようとする人をじゃまします。
私はもっともっと自動化できるものを自動化する、自動化できるんだということを伝える、自動化が当たり前だという考えを伝える、そして仕事とはともに働く仲間に責任を押し付けるものではないということを広めていきたいです。
そのために仕事の道具の1つとしてのITや、考え方や文化としてのモダナイゼーションやデジタライゼーションを1つの選択肢として広めていきたいです。
トレノケートのAWS研修（AWS認定トレーニング）
トレノケートのAWS認定トレーニングでは、AWS社の厳格なテクニカルスキル及びティーチングスキルチェックに合格した認定トレーナーがコースを担当します。AWS初心者向けの研修や、AWS認定資格を目指す人向けの研修をご提供し、皆様のAWS知識修得のサポートをいたします。
・トレノケートのAWS研修（AWS認定トレーニング）はこちら
▼AWS初心者の方は、
AWS Cloud Practitioner Essentials から！
座学中心の研修で、AWSを初めて学ぶ方や、営業などで提案に関わる方におすすめです。
「AWS Certified Cloud Practitioner」資格取得を目指す方の基礎知識修得にも最適です。
→ 詳細・日程はこちらから
▼実践スキルを磨くなら、AWS Technical Essentials で ！
実機演習が中心の研修です。仕事で構築作業を行う方や、シナリオベースの演習を通じて、実際に手を動かしながら各サービスの特徴を学びたい方におすすめのAWS研修です。
→ 詳細・日程はこちらから
いきなりの有償コースに抵抗がある方やまずはお試しをしてみたい方は、トレノケートが実施している無料セミナーがおすすめです。詳細はセミナーページよりご確認ください。
▼無料セミナーの詳細はこちらから
