2月24日、JAWS-UG大阪は第18回目となるJAWS-UG大阪の勉強会を開催した。「サーバーレス」をテーマにした今回の勉強会は参加者多数のため、ロックオン、アマゾン、アイレットの市内の3会場をリモートでつないで実施。スカイアーチネットワークス技術本部開発課の神津崇士さんは、社内システムやユーザー事例でのサーバーレス化の気づきを披露した。
1000台以上のサーバーから情報が集まるサーバーが悲鳴
「サバ缶屋」として知られるスカイアーチでAWS環境の設計や構築、PoC、自動化、CI/CD環境の構築などを幅広く手がけている神津さん。今回は大阪への出張と重なったタイミングで、JAWS-UG大阪での登壇になったという。
神津さんは前職では特定業種向けのASPサービスの企画・開発・運用を担当しており、ユーザー増で負荷が増大するインフラの設計や保守の重要性と楽しさを感じてきたという。「サーバーを買ってきて、RAID組むところから始めた。W-ZERO3にSSHターミナル入れて運用監視もやっていた（笑）」（神津さん）。
現在在籍しているスカイアーチはマネージドサーバー事業をメインに手がけているが、単なる監視や運用保守だけではなく、継続的な改善提案を提案していくことでお客様に価値を感じてもらっているという。「サーバーの管理で『サバ缶』なんですけど、最近は『ラム缶』も作りました（笑）。ゆくゆくはコードの管理までやっていきたいなと」とは神津さんの弁だ。
サバ缶だけじゃなく、ラム（Lambda）缶も投入したスカイアーチ
同社ではサーバーの安定運用のため、エージェントをベースにした監視の仕組みを入れているが、数年前からデータベースが悲鳴を上げ始めてきたという。「パーティショニングやRAIDの見直しなどいろいろ策を練ったが、1000台以上のサーバーがメールを送ってくるようになると、もはや限界。増え続ける情報も取りこぼすことになってしまう」（神津さん）。こうした課題を解消すべく、スカイアーチでは監視システムを刷新。Chefでサーバーの状態を取得し、API Gateway経由で社内のMongoDBに情報を登録するように構築し直したという。これにより処理能力は以前に比べて約10倍向上。今後は機械学習の導入や見える化を進め、顧客に向けた継続的な運用改善の提案を加速していきたいという。
API Gatewayを用いた新しいサーバー監視の仕組み
実質1週間で重たいバッチ処理のサーバーレス化を目指す
続いて神津さんは、重たいバッチ処理のサーバーレス化を進めたユーザー事例を紹介。「m4.x4larageに4時間かかるジョブと2分で終わるジョブが混在したバッチ」を並列実行させる仕組みを、1週間という超短期間で納入した経験を披露した。
予想以上に重かったバッチ処理を並列実行させたい（しかも1週間以内で）
与えられた1週間の構築期間のうち、6日目まではバッチプログラムの動作調整と並列実行方法の選定に四苦八苦しつつ、バッチの並列実行のためのAWS Data Pipelineを導入することにした。とはいえ、AWS Data PipelineはGUIにけっこう癖があり、こちらも難渋。なんとかS3バケット上に置いたスクリプトを、AMIから生成したバッチサーバー上で実行できるようになった。しかし、「これでなんとか期日に間に合うかと思ったら、並列実行の数が足りないという不吉なエラーメッセージが出てきた」（神津さん）ということで、オンデマンド実行の並列動作に失敗してしまったという。
7日目にしてData Pipelineのオンデマンド実行で痛恨のエラーメッセージ
急遽ユーザーの許可を得て、なんとか7日・8日目の2日を確保した神津チームは、結局方針を変更。AWS CLIを用いたAMIからのバッチサーバー生成の際に、ユーザーデータを用いてパラメーターを引き渡すことにした。Amazon S3から最新のスクリプトとバッチファイルを取得し、バッチサーバー上で実行。結果とログをAmazon S3にアップロードするという方法に落ち着いた。ここまでであればサーバーレスの事例ではないが、バッチを終了したり、長時間残留しているサーバーの削除作業はLambdaの定期実行で実現しているという。
8日目の延長戦でなんとかシステムを実現
事例について神津さんは、「開発に際しては、使いどころがきちんとフィットするかを確認しなければならない。あとはスケジュールが重要。今回もPoCフェーズがあればよかったけど、とにかく納期が短かった」と振り返る。実際試してないと仕様がわからないというのは、まさに「はまったから」こそのコメントだ。（神津さんの娘さんのように）普段からサーバーレスに慣れ親しんでおくことが重要だと聴衆にアピールした。
普段からサーバーレスアーキテクチャに親しむことが重要
サーバーありきの監視ではうまく対応できないことも多い
最後、神津さんはサーバーレスでの監視の課題についても語る。サーバーレスの監視においては、Amazon CloudWatchからのアラートメールが重要になるが、文面的にわかりづらいことも多い。そのため、スカイアーチではIFTTT的なサービスを用いて、メールを対応者にわかりやすい形に整形してから送信している。たとえば、AWSのアカウント等で条件を振り分けたり、先頭に案件やお客様の名前を追加し、オペレーターが対応しやすいようにしているという。人にとっても運用しやすい仕組みが重要ということだ。
CloudWatchからのメールをわかりやすい形に整形
今までの監視と異なる点にも留意する必要があるという。通常、インフラの監視においては、ネットワークやハードウェア、OS、ミドルウェアなど階層ごとの監視が重要だが、クラウドの場合サーバーありきで考えると、なかなか難渋することも多い。たとえば、Webサーバーはオートスケールするが、データベースがスケールしないために接続できないという例だ。この場合、コネクション数が最大数になったり、MySQLのファイアウォールが発動したことで特定のホストからつなげない、あるいは運用時のSecuriryGroupが設定ミスでアクセスできないこともある。
こうした事態を防ぐべく、最近ではWebシナリオ監視とは別に、独自のサービス監視用ページで作り、切り分けや対応速度を上げることが多いという。具体的にはLambdaで監視用のリクエストを送信し、定期的にレスポンスを調べているという。今後、re:Inventで発表されたStepFunctionsが進化すれば、複数のLambdaを組み合わせ、より複雑なシナリオでの監視が可能になると神津さんは期待する。
Webのシナリオ監視とは別個での監視が重要
神津さんは、サーバーレス化を実施するにあたっては、①サービスの運用しやすい環境を整える、②ロードテストを実施し、スケールするかを確認、③サービス監視と状況把握するための可視化、などが必要になるとまとめる。同社のサーバーレス案件も昨年に比べてどんどん増えている状態。神津さんは、「MSP事業者であるわれわれも日々鍛錬している最中なので、運用フェーズからではなく、PoC段階からお客様には相談いただきたいと思います」とアピールして、セッションを終えた。
