AWSの話題を中心に、日々の業務やプログラミングの徒然を綴るエンジニアブログです。

HANDS LAB

HANDS LAB ENGINEERS BLOG

ハンズラボエンジニアブログ

カテゴリー: AWS

AWS認定ソリューションアーキテクト – プロフェッショナル(改定後) おすすめ学習方法

Pocket

はじめに

ビジネスソリューション本部のフジワラです。

問題改定後のAWS認定ソリューションアーキテクト – プロフェッショナル(以後SAPと記述)を受験し、1度の不合格の後、2019/7/25 に スコア750というギリギリで合格できました。

2019/2に問題が改定された後のSAPはインターネット上に情報が少なく、情報収集に非常に苦労しました。そこで、全く自慢できないスコアではありますが、試験の概要と私が実施した学習方法を共有したいと思います。

試験について

概要

  • 問題数:75問
  • 制限時間:180分
  • 合格ライン:75%正解
  • 日本語訳文と英語原文を切り替え可能

75の長文問題を平均して2〜3分以内に回答する必要がある上、試験途中の飲食や休憩は許されないため、体力勝負になります。体調をしっかり整えての受験をおすすめします。

範囲

問われるユースケースは非常に幅広く実践的です。アソシエイトではサービスの機能そのものを問われる問題が多かったと記憶していますが、SAPではサービスの機能を把握した上で「何を求められている問題なのか」を読み解き、解答する必要があります。今求められているのは、コストを抑えることか?それとも作業の容易さか?それとも完了までのスピードか?読み解く力が必要です。 

誤訳に注意

日本語版試験を受験しましたが、たびたび誤訳に苦しめられました。日本語文ではどの選択肢も不正解になってしまう… → 英語原文に切り替えると記述内容が異なる! ということも数回ありました。日本語問題文に関係しないサービスが突如現れた場合等は、英語原文に切り替えて確認することを強く推奨します。

誤訳問題をAWSに報告するには一体どうすれば良いのでしょうか……

学習方法

何もわからず手探りで行った学習と、2度の受験経験を合わせて考えて再構築した、私がもう一度SAPを受験するなら… と考えた学習方法を紹介します。

AWS公式デジタルトレーニング

実はSAP試験対策用のデジタルトレーニングがAWSから提供されています。英語ではありますが、とてもリッチでわかりやすく有用な学習資料です。しかも、なんと無料です!

この「Exam Readiness: AWS Certified Solutions Architect – Professional」では、SAP試験範囲である以下の項目について、基本的な学習を行えます。

  • 組織の複雑さに対応する設計
  • 新しいソリューションの設計
  • 移行の計画
  • コスト管理
  • 既存のソリューションの継続的な改善

全編英語ですが、Chromeのgoogle翻訳拡張を使えば、容易に翻訳可能です。

各章の冒頭にはアーキテクトを解説する動画があります。当然英語ですが、私のような英語ダメダメ人間は動画に文字が表示されたタイミングで停止して、スマホ版Google翻訳のカメラ機能を利用して内容を理解しました。もちろん、英語をヒアリングできれば1番良いのですけど…。

デジタルトレーニングには例題と、その例題に対する解説動画も用意されています。特に例題解説動画は誤まった選択肢についても一つ一つ丁寧に説明してくれるため、必見です。Ask yourself:

解説動画を全て見ていくと4時間以上かかりますが、動画にのみ出現する構成図も存在するため、なるべく飛ばさずに視聴することをオススメします。本トレーニングを修了することで、SAP試験対策の基礎は整うはずです。

また、私は受講できていませんがSAP向けの無料デジタルトレーニングは他にも存在するようですので、そちらも合わせて受講するのも良いかもしれません。

AWS クラウドサービス活用資料集

先述のデジタルトレーニングで大方の雰囲気は掴めたはずですが、各サービスのベストプラクティス などの詳細部分までは説明されていません。トレーニング中に出てきたサービスについては、おなじみのAWS クラウドサービス活用資料集で追加学習することをオススメします。

ホワイトペーパー

SAP試験ガイドに記載のあるホワイトペーパーを少し読みました。ホワイトペーパーは文量が膨大かつ日本語化されてないものも多く、読み進めるのが辛いため、設計思想のおさらいという感覚で軽く読みました。「AWS Well-Architected Framework」についてはBlackBelt化されていましたので、そちらで学習しました。

その他

ここ1年以内にリリースされた新し目のサービスに関連する問題もありました。AWSに関する情報は広く貪欲に集めておくことをオススメします。

おわりに

私がデジタルトレーニングの存在に気付いたのは、2回目の試験の前日でした。もっと早く存在を知っていればもう少しマシなスコアが取れたかもしれない…と考え、この記事を書きました。改定後SAP取得を目指す、何処かの誰かの助けになれば幸いです。

それにしても、デジタルトレーニングにせよ試験の誤訳にせよ、今1番必要なのはAWS認定ではなく英語のスキルなのでは……

Pocket

すごいVBAをLambda+HTML帳票+Puppeteerに置き換えた話

Pocket

CRMチームのyktakaha4です。

今日は、私たちが日々開発・運用しているハンズネットにおけるレガシーマイグレーションの現場をお届けします。

みなさんは、Excel、とりわけVBAはお好きでしょうか?

方々のエンジニアから親の仇のように忌避されながらもなぜだか中々無くならず、今日においても大小様々な企業で使われ続ける不思議な存在です。
嘘だとお思いでしたらInxxxxやレバxxxで「VBA」で検索してみてください。年収700万円も夢じゃないみたいですよ…?

私はExcelもVBAも好きです(でした)。

Officeの入ったWindowsがあれば使えるという可搬性に加え、
ユーザーフォームやExcel関数、CreateObjectやDeclareまで駆使すれば、控えめに言ってどんな処理でも実現できます。
また、Numbersやスプレッドシートの関数名、GASにおける各種オブジェクト名なんかを見ても、彼らがいかに広く浸透した概念であるか分かります。

前職では金融系の社内システムを開発していたのですが、資格を取得するくらいには活用していました。
もちろん不満・力不足に思う部分も沢山ありますが、エンドユーザと同じコンテキストを共有できて、どこでも使えて何でも作れるって、それ普通に全エンジニアの夢じゃないかと思うのですが…!

しかしながら、潮目は少しずつ、でも着実に変わってきています。
過去にはExcelでPythonが使えるようになるかもというニュースがあったり(結局JavaScriptになったんでしょうか?)、東急ハンズでも各種RPAツールの導入や、G Suiteの利用を推進していたりと、その利用の場は減っています。
令和の時代にはきっと新たな何かが世を席巻し、その陰に消えゆく運命にあるのでしょう…

そんなVBAに最後の餞として用意されたかのごとく、東急ハンズでExcelとVBAが大活躍する業務がありました。

そう、ハンズネットの荷札発送業務です。

ハンズネットは、すごーく大まかに言って、東急ハンズ新宿店の在庫をバックヤードで梱包してヤマト運輸経由で発送しています。
ヤマト運輸で商品を発送するためには、所定の送り状にお届け先の情報を印字してダンボールに貼り付ける必要がありますが、
この荷札の作成及び印刷をExcelとVBAマクロを駆使しておこなっていたのです。

図にあらわすと以下のような感じです。

出荷担当者目線では「梱包作業の時間になったらWebの画面にボタンが出るんで、押したら荷札が出てくる」程度のものですが、
システム担当者からすると、業務ロジックに基づいた荷札種類の決定、データへの書式設定、mm単位での微調整が必要なレイアウト、バーコードの生成、複数プリンタを指定する必要のある印刷処理などが渾然一体となったすごいやつ(尊敬)を保守し続けなければならず、
私含むエンジニアのほぼ全員がMacbook Proで開発を行なっている現状においては、環境を用意するだけでも一苦労…という状況でした。

そんな中、今年の10月に施行される消費増税、とりわけ経過措置としての軽減税率導入へ向けた対応の中で、当マクロの改修が必要なことが分かりました。
東急ハンズでは軽減税率対象となる食料品を一部扱っており、税率を分ける必要がある→荷札と一緒に添付する領収書で表示する税額を分けたり、商品ごとの税区分を明示する必要があったんですね。

現行のマクロを改修するという逃げの一手もありましたが、CRMチームのエンジニアリーダであるwatarukuraさんの判断もあり、この機会に保守が容易な別の仕組みに置き換えようという運びとなりました。
(私見ですが、こうした判断をエンジニアサイドから自発的におこなえるのは弊チームの良いところの一つだと思います。こちらもよければご覧ください)

今回は、マイグレーションによってコードを保守可能なものに置き換えることと、複数システムにまたがる税対応の中でスピード感を持って改修することを優先し、
外部サービスやパッケージを使うといった抜本的な運用変更までは考えず、既存と同等の荷札を別の仕組みで出力できるようにする…という方向性で改修方針を立てました。

改修後は以下のようになりました。

ユーザ目線では、従来Web画面でボタンを押下した際に自動的に荷札が印刷されていたのが、
出荷対象の全ての荷札が印字されたPDFファイルがダウンロードされるのでそれを印刷する…という形になっています。
印刷方式についてはチーム内でも議論がありましたが、業務部門のOKをもらった上で、今回の作業スコープからは一旦外すこととしました。
(運用がこなれてきたらより良い形を考えて、改めて提案したいですね…!)

業務的な話とは別に、本対応のキモであるVBAをPDF生成APIに置き換えた部分をもう少し詳しく紹介しておきます。

大枠では、VBAに組み込まれていた業務ロジックとデータへの書式設定をNode.jsに置き換えた上で、Excelでレイアウトしていた荷札をテンプレートエンジンであるEJSを用いたHTML帳票として出力し、それを更にGoogle ChromeのヘッドレスブラウザのPuppeteerでPDF化する…という感じです。
HTMLならVBAよりは修正にかかる心理的負荷を軽減できますし(WinMergeを使えば…とかあるかもしれませんが、コードでそのまま比較できるのはデカいと思います)、PDFはフォントや画像埋め込みもできて環境差異が出づらく、かつ業務部門にとってもある程度扱えそうなものだったため、利用技術として選定しました。
Puppeteerを使ったのは、公式で活発に開発が行われていたからというのもありますが、東急ハンズではGoogle Chromeを社内標準のブラウザとして定めており、色々知見が溜まれば今後に活かせそうに思えたからです。

また、今回の業務要件特有の話になりますが、1日の間に締め時間が数回あり、その時点までに受け付けた注文をなる早で荷札出力する必要がある…という課題がありました。
一回の締め処理で扱う注文数は、業務的な繁忙期も考慮すれば最大で約1000注文程度を想定しなければならず、
処理量に応じていい感じにスケールアウトしつつ、出荷のない夜間帯などはお金が掛からない仕組みを構築したいと考えていました。
あと、細かい話ですが、プリンタがジャムったり締め処理後に注文情報が変更になった時用に、個別に荷札を再印刷する機能も作らなければならず、バッチ・Webの双方から呼び出し可能なAPIである必要もありました。

これについては、社内でも幾つかのプロジェクトで利用実績のあったServerless Frameworkを使って、APIとしてリクエストを受ける親のLambda関数と、EJSによるレンダリング〜PuppeteerでPDF出力までを担う子のLambda関数をそれぞれ別に定義し、処理量に応じて子Lambda側の並列実行数を増やして対応することとしました。

平行処理については、作る前は苦戦しそうかな…?と思っていた部分だったのですが、結果的にはほとんど詰まるところがなく、改めてマネージドサービスは便利ですごいな…と思い知りました。
また、Serverless Frameworkについても、ソースコードのパッケージングからデプロイ、関数毎のメモリ使用量やタイムアウト秒数まで面倒見てもらえるので、本番デプロイなどコマンド1発で済んでしまい、大変助かりました。

最後に。
ご参考まで、対応前後の荷札サンプルも貼っておきます。今まで単に荷札と説明してきましたが、右部は商品明細になっていて、切り取ってダンボールの中に入れるようになっています。
上が対応前(VBA)、下が対応後(PDF)です。開発中の写真で位置調整が甘いですが、なんとなく雰囲気は分かってもらえるのでないかと思います。

VBA版
PDF版

余談ですが、従来バーコードコントロール9.0でおこなっていたバーコード出力はJsBarcodeを使うようにしました。フォントもおなじみMSゴシックからNoto Sansに変えたので、なんとなく見やすくなった感じがしますね。

現在は、従来のExcelバージョンとPDFバージョンを双方出力できるような状態で本番化して、処理量と処理速度を監視しつつ、業務部門に不都合がないか最終確認してもらっている段階となっています。
消費税対応のためにはじめたマイグレーション作業でしたが、これをきっかけに、実は他にも荷札で直したいところがあって…というような依頼もいくつか頂くようになり、業務改善にも寄与できそうでいい感じです。

っていうか、ようやく税対応のスタート地点に立つことができたという話なので、
これがキャリア最後のVBA対応になることを強く願いつつ、もう一息頑張っていきます…!

Pocket

バッチ処理をECSに移行した話(GitHubActionsもあるよ)その2

Pocket

こんにちは、ハンズラボの清水です。東急ハンズのECサイトを担当しています。今回は前回の続き、GitHubのリポジトリにpushしたらECRへpushを行うGitHubActionsを紹介します。

前回の記事はこちら
バッチ処理をECSに移行した話(GitHubActionsもあるよ)その1

前回の記事の追記(Fargateになりました)

前回の記事のクラスターを作成にEC2を利用しましたが、その後、NATGatewayにElasticIPをつけることでFargateで出て行くIPアドレスを固定することができたのでFargateになりました。

IPアドレスを固定する理由は外部ECモール(yahoo, 楽天など)のAPIを利用する際、IPアドレスの制限があるのでIPを固定しています。

GitHubActionsを作成する

ここから本題!GitHubのリポジトリにpushしたらECRへpushを行うGitHubActionsを作成していきます。
参考にしたもの(https://github.com/actions/example-aws)

主な流れはこんな感じ

  1. GitHubのリポジトリにコードをpushする
  2. docker buildを行う
  3. dockerにタグをつける
  4. AWSのアカウントにログイン
  5. ECRにpushする

GitHubのリポジトリから作成します。
作成を行うとプロジェクト内に.github/main.workflowというファイルが作成されます。GitHubActionsのGUIで作成も出来ますし、main.workflowを編集して作成もできます。

個人的にはGUIで大まかな流れを作成して、main.workflowを編集するやり方が個人的には作成しやすいです。

main.workflowの見方

がっつりmain.workflowを書くことはありませんが、GUIである程度作成してしまえばいいので編集するのはenvargsくらいです。
usesは使用するdocker imageです。(独自の環境での実行もできます)

作成したもの

各説明(処理の流れ)

1. ブランチをフィルタリングする

pushされたブランチがmasterの時のみ下に処理を流します。
GitHubActionsでは条件分岐ができないのでFillterを使用しています。

2. イメージのbuild, ECRへのログイン, slack通知

ここではイメージの build、ECRへのログイン、slackへの通知を並列で実行します。

やっていることはdocker build -t test-python . –build-arg STAGE=$STAGEのコマンドを実行しています。

ECRへのログインも先ほどのdocker build同様にawsのコマンドを実行しています。secretsAWS_ACCESS_KEY_IDAWS_SECRET_ACCESS_KEYをセットすることでECRにログインできます。

secretsの登録は割と簡単です。

slack通知はsecretsにwebhookのURLをセットしてargsにチャンネルに通知するメッセージを設定します。

3. dockerイメージにタグをつける

行なっていることは上記のコマンドと同じですコマンドではバージョンをlatestとしていますが、GitHubActionsではバージョンにブランチ名が適応されます。

4. ECRへpushする

dockerイメージのタグ付け、ECRへのログインが終わり次第ECRへpushを行います。

行なっているコマンドは同じですがバージョンのlatestは今回masterになっています。ECSのタスク定義でイメージのURLをlatestにしている場合はmasterに変更しましょう。

5. 完了通知をslackに飛ばす

2. の工程で説明を行なっているので省略します。

masterへpushを行うと、リポジトリのActionsタブから実行ログを見ることができます。

GitHubActionsを使って見ての感想

良い点

  • 作成が簡単
  • 処理の流れが見やすい
  • Dockerとの相性が良い

悪い点

  • ブランチごとにActionsを定義できない
  • 条件分岐が使用できない(失敗したら~~するとか)
  • AWSの複数アカウントに対応できない(Keyを1セットしか登録できない)

現在GitHubActionsはPublicBetaなので今後の機能追加に期待しています。

Pocket

バッチ処理をECSに移行した話(GitHubActionsもあるよ)その1

Pocket

はじめに

こんにちは、ハンズラボの清水です。東急ハンズのECサイトを担当しています。今回はEC2上で動いている外部ECモール連携バッチをAmazon ECS ScheduleTaskに移行しました。そして、GitHubにpushした際にECRにイメージをpushできるようなGitHubActionsも作成しました。今回はECSのScheduleTask機能を使用してバッチ処理を作成していきます。

※外部ECモールとはyahooや楽天といったショッピングサイトのことです。

既存バッチ処理の内容

既存のバッチ処理ではEC2インスタンス上にバッチサーバーを用意、cronにスケジュールを登録してバッチを叩いています。
処理の内容としては、Auroraに追加された注文変更情報を取得して、注文情報商品の数量変更、注文キャンセル等を行っています。
今回は注文情報変更処理をECSに移行しました。

ECSへ移行

移行の理由

移行の理由としては以下の点が挙げられます。

  • AWSのサポートを受けられる
  • 各バージョンアップに対応できる
  • EC2を冗長化したい
  • dockerを使用するのでローカルでの開発が楽になる

注文情報変更の処理のみをdockerのイメージとして切り出し,ECR(Amazon Elastic Container Registry)にpushします。 Amazon ECS ScheduleTaskでスケジュールを指定して、処理を開始します。

ECRの作成

ECR(Amazon Elastic Container Registry)の作成を行い、ローカル開発環境にあるdockerイメージをECRへpushします。はじめにECRでリポジトリを作成しましょう。作成したらリポジトリ名をコピーしておくと後々楽です。

dockerイメージの作成&ECRへpush

ECR(Amazon Elastic Container Registry)へpushする用のdockerイメージを作成して,pushしましょう。以下のbashスクリプトで行いました。

のちのAmazon ECS ScheduleTaskで説明しますが作成したDockerfileENTRYPOINT"/bin/ash"のようにしておくとコンテナの挙動を変更できます。(今回はpython:3.7.3-alpine3.8を使用したのでashです)

クラスターを作成

ECSからクラスターを作成します。クラスターのテンプレートですが、今回は出て行くIPアドレスを固定したいためFargateを使用せずにEC2を利用しました。 クラスターの設定は各自お任せします。

後に気づいたのですが、NATGatewayにElasticIPをつけることでFargateでもIPアドレスを固定できます。

タスクを定義

ECSからタスクを定義します。起動タイプはEC2を選択。

コンテナ定義でコンテナの追加します。イメージには先ほど作成したECRのURLのパスを貼り付ければOK。

環境のコマンドに今回はテストとしてecho testを実行します。

ログ設定のAuto-configure CloudWatch Logsにチェックを入れておくとCloudWatch Logsにログを吐いてくれるのでチェックを入れました。

タスクを実行してみる

作成したクラスター→タスク→新しいタスクの実行からタスクを実行する。 先ほど作成したクラスターとタスク定義を選択をして実行しましょう。 実行ログはCLoudWatchLogsに吐かれるので確認しましょう。

成功です。

スケジュールを設定する

作成したクラスター→タスクのスケジューリングから作成します。
スケジュールタイプはCron式でも設定できます。タスク定義を先ほど定義したタスクを設定して作成完了です。

CloudWatchLogsでログを確認したところスケジュール通りに動いてくれています。

ハマったところ

タスクが実行されない(CloudWatchメトリクスにFailedInvocationsが出ている)問題がありました。調査の結果以下の二つが問題の原因でした。

  • インターネットに接続出来ていない(ElasticIPを付与したら解決)
  • コンテナインスタンス IAM ロールに権限が付与されていない(IAMロールからECSFullAccessつけることで解決)

終わりに

今回はECSのECS ScheduleTaskを利用してバッチ処理を移行しました。次回はGitHubActionsを利用したECRへのpushを紹介できればと思います。

Pocket

re:Invent 2018 参加レポート NPO HACKATHON FOR SOCIAL GOOD その1

Pocket

ラスベガスから日本に帰ってきました。人見です。

NPO HACKATHON FOR SOCIAL GOOD
なるものに参加して来たのでレポートします。

NPOハッカソンはre:Invent 2018のハッカソンイベントの中の1つで
複数のNPOから提示された課題の中からチームで一つ選んで開発するハッカソンです。
NPOは非営利団体のことです。

スケジュールでは9AM–MIDNIGHTと記載されており、
実際に朝8時開場で深夜1時になってもまだ終わらないという感じだったので
おそらくre:Inventのイベントの中でも最長のものだと思います。

朝のラスベガス

夜中のラスベガス

チームは5人までで、自由に組むことができます。

実は前日にハッカソンのチームを組むイベントがあったらしいのですが、
私は当日にチームを組みました。

こんな感じの紙を受付でもらって、

自分がどの役割なのかを自己紹介しながらチームメンバーを探します。
私はバックエンドエンジニアにしました。

メンバーが見つかるか不安だったのですが、
AWSの方もチームを探すのに困ったら手伝うよと言ってくれましたし、
当日オロオロしていたら、声をかけてもらえてチームに入ることができました。
すごいフランクな感じなので、英語が苦手でも大丈夫だと思います。

チームで席を決めてからは、自己紹介タイムで
自分が作ったことあるものや、使ったことのあるAWSのサービス
AWS利用歴などを話しました。
まだハッカソン開始前でお題は発表されていなかったのですが、
NPOならコストかけない方がいいからサーバーレスがいいよねとか、
DynamoDBがいいよねとか、課題を想像しながら戦略を話し合いました。

ハッカソン開始になってオープニングムービーが流れ、
各NPOから解決したい問題が発表されます。
この課題発表の英語のリスニングが超絶難しくて、ざっくりとしか概要をつかめず焦りましたが、
その後のチームメンバーとのディスカッションの時に聞いたり、
NPOの方に質問できる時間があったのでなんとか理解することができました。

私のチームはCompassionという団体の課題を選びました。
課題は「子供とスポンサーがスムーズにコミュニケーションすることができるツール」の開発です。

求められてる機能としては
・ 音声や動画のライブコミュニケーション
・ レスポンスが早いこと
・ 翻訳機能があること
・ 汚い言葉を検知して、除外すること
・ 発展途上国での通信環境も考慮すること

などなど、要件がたくさんありましたが、
ざっくりまとめると

「世界中の色々な言葉を話す子供たちと健全に会話ができるツール」

の開発です。

そんなこんなで開発がスタートしました。

その2へ続きます。

Pocket