JAWS FESTAの地元企業セッションに登壇したサタケのAWS活用術

作業服姿の初心者風情にだまされた！　AWSでこんなに作業を自動化するなんて

　広島大学で開催されたAWSユーザーグループのイベント「JAWS FESTA 2024」。地元企業事例のセッションで登壇したのは、精米機や乾燥機を製造するサタケの堀岡和則さんだ。作業員姿の初心者風情で始めたAWSの活用紹介だが、話が進むにつれ、けっこうAWSを使いこなしていることが発覚。課題に対して、自らサービスを探し、学ぶエンジニアだったのだ。

農家の長男が今ではIoTシステムを開発　無線とAWSの毎日

　県知事まで登壇した基調講演の後、参加者は三々五々で各セッションに会場に散っていく（関連記事：失敗してもいいじゃないか　JAWS FESTA 2024で広島県知事が熱いメッセージ）。私はせっかく広島に来たので、県内の事例トラックに張り付くことにした。もちろんほかにも見たいセッションはいっぱいあったのだが、仮想化して各セッション会場にデプロイという訳にもいかないので、こればかりはしようがない。

　最初はサタケのエンジニアが語る「乾燥機監視システムのAWS移行」というセッションだ。Tシャツ姿の多い会場において、登壇者である堀岡和則さんの作業服は否が応でも目立つ。しかも、「初心者なので、お手柔らかに」みたいな初心者風情を醸し出していたため、会場も温かく見守ろうという雰囲気だったのだが、今から考えれば、これも堀岡さんの策だったのかもしれない。

　さて、サタケは1896年創業の老舗企業で、精米機や乾燥機、選別器などを中心にした食品加工機械を製造・販売している。世界で初めて機械式精米機を世に送り出し、業界トップシェアを誇る。現在は画像処理やAI・ディープラーニングなどを活用した光選別器を開発したイノベーティブな企業としても知られ、しかも世界150カ国以上に展開しているとのこと。完全にモグリなのだが、こんなすごい会社を知らなかった。

　堀岡さんはサタケのデジタルソリューショングループ IoTシステム開発チームに所属する。もともとは会場のある西条の農家の長男で、中学校の社会科の先生になるはずだったが、転職の末にサタケに入社。現在はIoTシステム開発チームで、産業用無線通信、WebとAWSの毎日を送っているとのことだ。

止まると農家が困る穀物乾燥機　遠隔監視をAWSに移行

　さて、そんな堀岡さんが手がけたのは穀物乾燥機の遠隔監視だ。穀物乾燥機は、文字通り収穫した稲刈りした米をタンク内で乾燥する装置。稲は刈り取り後、速やかに乾燥しないと、変色して、品質が落ちるリスクがあるため、農家にとっては大事な機械だ。では、なぜ遠隔監視が必要かというと、「今日どれくらい稲刈りできるかを知るため」だという。

　米の収穫期、農家は夕方までに稲刈りを行ない、穀物乾燥機で翌朝まで乾燥させる。そのため、乾燥できる稲の量はタンクの容量に依存しており、タンクに入りきらなかった稲は乾燥できず、変色の原因となってしまう。そのため、今日どれくらい稲刈りするかを知るためには、タンクの残量をなるべくリアルタイムに把握する必要があるわけだ。

　また、乾燥機が夜中に止まってしまうと、翌朝までに乾燥が完了しない可能性がある。乾燥機は灯油を燃焼して、熱風で半日かけて乾燥を行なうため、途中で灯油が切れると、翌朝までに乾燥が完了しない。そのため、夜中に乾燥機で問題が発生した場合に通知がほしいというニーズがあったという。

　AWS移行前、サタケではこの乾燥機の遠隔監視を他社クラウドで実現していた。運転情報をクラウドにアップし、スマホから確認できるサービスだったが、料金値上げの通知がときどき来るのと、アプリのデプロイがSFTPでアップロードし、設定変更をSSHで行なうという前時代的な方法だった。結局、やりたいことに対してコストが高く、手作業が多いのが課題だったわけだ。

　そこで、サービスをAWSに移行することにした。調査によると、維持コストは約20％削減できるほか、フルマネージドサービスであるため、開発や運用の負担軽減ができる見込みが立った。もちろんグローバルNo.1のシェアを持つため、知見の共有も豊富だった。さっそく、試験用のアカウントでAWSにシステムを構築してみたという。

自動化にCloudFormationフル活用　アプリのデプロイまでCodeCommitで

　さて、いざ本番システムのためのAWSアカウントを作ろうとしたが、「どこに何を設定したのか覚えてないんですう」という状況に。移行手順に関しても、画面のスクリーンショットを撮って説明を書く伝統的な手順書は避けたい。そんなときに知ったのが、システム構成をテンプレートして記述し、作業を自動化できるCloudFormationの存在だ。さっそく試して、AWS SMA CLIでデプロイし、EC2など必要なリソース作成を手順化・自動化することに成功した。

　続く課題は今までSFTPを使って「人手」で搬送していたWebアプリのデプロイ。こちらも簡単な作業にしないと、将来困る可能性ありということで、今度はアプリのデプロイを自動化するCodePipelineの利用に行き着く。マネジメントコンソールからチャレンジした結果、CodeCommitにソースコードを保存するだけで、インスタンスにアプリをデプロイ成功するようになった。

　3つ目の課題はCodePipelineの設定を覚えていないという問題。しかし、これは上記の2つを組み合わせればOK。つまり、CodePipelineをデプロイするためのCloudFormationテンプレートを作成すればよいのだ。実際に、AWS SMA CLでデプロイし、CodePipelineに必要なリソースを作成することに成功。ここまでくると、「初心者な空気出していたけど、めちゃAWS使いこなしてんじゃんｗww」みたいな空気が会場にも流れ始め、参加者のリアクションもがぜん盛り上がってくる。

　さて、AWS移行の当日。CodePipelineをデプロイし、CodeCommitにPushするだけで完了！……なはずだったが、実は本番システム用のSSL/TLS証明書がないことに気がつき、AWS Certificate Managerを使い、当日ぶっつけ本番で証明書をリクエスト。証明書にはDNSによる検証が必要だったため、会社のドメイン管理者に依頼し、DNSサーバーのゾーンファイルに検証用レコードを追加。DNS検証が成功したため、証明書をALB（Application Load Balancer）にひも付けることが可能になり、無事が完了した。

課題に対して自ら探し、自ら学ぶ姿勢を学びたい

　最後、堀岡さんは移行後に気がついたことも説明してくれた。まずはマネージメントコンソールでの不明点が減少したことだ。堀岡さんはCloud Formationテンプレート作成において、AWS公式ガイドのユーザーガイドを読む機会が増えたという。その結果、テンプレート化したいリソースを検索し、該当ページを読むことで、設定項目に対する理解が大幅に向上したという。

　また、クラウドリソースの転用コストが大幅に削減された。「開発系」「検証系」「本番系」の3つのアカウントがあっても、各AWSアカウントでCodePipelineをデプロイしてしまえば、CodeCommitにPushするだけで対応可能。動作確認がしやすくなったので、開発中の不安が大幅に軽減したという。

　CI/CDの社内展開も容易にあった。今まではCI/CDを導入しようと行っても、「専用のPCを導入し、次にJenkinsをインストールし……」といった感じになり、ハードルが高かった。PC購入の稟議書をわざわざ書くのも面倒だし、Jenkinsのようなツールの管理も大変だからだ。しかし、CodePiPelineを使うことで、導入のハードルは大幅に探すことになったという。

　ただ、残念ながらCodeCommitは、2024年7月25日に新規利用が終了となってしまい、代替を検討する必要が出ている。また、証明書発行もCloudFormationでテンプレート化していく予定。さらに今まで案件ごと「開発系」「検証系」「本番系」に別れていたアカウント管理が大変になってきたため、AWS Control Towerの導入も検討しているという。

　ということで、「初心者風情を見せていた登壇者が、実はけっこうAWSの使い手だったよ」というセッション。歴史のあるAWSだけに、ユーザーによって、リテラシやノウハウの差はかなり大きくなっているが、堀岡さんは自らぶち当たった課題に対して、適切な解決策と学び方を自ら得ているという点が素晴らしいと感じられた。なにより、堀岡さんが事前に立てた「フラグ」通りに、きちんとしくじるので、会場も大盛り上がり。ユーザーがユーザーに語りかけるコミュニティらしさを満喫できたセッションだった。