クラウドジャーニー記録②
社内とAWSとのネットワーク設定作業
情報システム部と連携し、下記作業を実施。
■情報システム部と取り決めたこと
・IPアドレスについて（CIDR）
→ 社内とAWS上で、IPアクセスが重複しないようにAWSで利用するCIDR範囲を取り決める
・オンプレ側で利用しているIT資産管理ツールの導入可否
→ ハードが無いクラウド上のサーバ資産を管理することは困難であるため、クラウド上の資産はAWSのサービスで管理することに
→ ただし、ライセンス管理対象の製品「Office」を入れる場合は既存のIT資産管理ツールを入れて監視したい。
■社内
・疎通を許可するセグメント及びIPの調査と設定
・L3スイッチの経路情報追加
・Firewall（Fortigate）の設置
・VPNサーバ設置
■AWS側
・CustomerGatewayの作成
・Transit Gatewayの作成
対象のVPCをアタッチ、ルートテーブルへの経路情報追加
・Route53 Resolverの作成
社内AD（DNS）で名前解決できるように設定
・アウトバウンドエンドポイント作成
（参考）転送ルールの設定→アウトバウンドエンドポイントとVPCの関連付け
https://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/resolver-rules-managing.html#resolver-rules-managing-associating-rules
（参考）転送ルールを他のアカウントと共有
https://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/resolver-rules-managing.html#resolver-rules-managing-sharing
社内からAWS側のDNSを参照できるように設定
・インバウンドエンドポイントの作成
（参考）リモートネットワークからプライベートホストゾーンの DNS レコードを解決するように Route 53 リゾルバーのインバウンドエンドポイントを設定する方法を教えてください。
https://aws.amazon.com/jp/premiumsupport/knowledge-center/route53-resolve-with-inbound-endpoint/
その他、オンプレのサーバをSSMで管理できるよう対象サーバにSSMエージェントをインストールした。
メンテナンスウインドウ・パッチマネージャを利用することで、今後のWindowsUpdate作業を自動化し、運用負荷の削減を狙う。
社内ADを使ったSSOは今のところ考えていないため、連携については今回は実施せず。
今後、全社展開となったらコンソールアクセスをAD認証できるようにしたい。
クラウドジャーニー記録①
久しぶりにブログ書きます。
ついにわが社で念願のAWS移行が始動しました。
せっかくなので、今後のクラウド移行の貴重な経験を記録していきたいと思います。
これまでの私の活動と会社の動きを振り返ります。
2017年
・仕事で初めてAWSに携わる
・AWSのインフラ設計及びクラウドネイティブアプリケーションの開発を経験
・AWS認定資格取得(デベロッパーアソシエイト）※社内で先駆けてAWS資格取得
2018年
・AWSの社内勉強会を開催（事例発表含む）
（※子供が生まれて育児に追われ活動ができませんでした・・）
2019年
・AWS案件経験（サーバレス）
・AWS認定資格取得(ソリューションアーキテクトアソシエイト）
・社内でAWS技術発表やハンズオンを開催
・JAWS-UG nagoyaに参加 → AWS営業の方と知り合う【情報収集と学習】
→ それをきっかけに社長や役員が動き出す【エグゼクティブスポンサーの獲得】
2020年
・社長承認でAWS活用推進の方針が決定
→ APNパートナーセレクトを目指すことになり、資格取得を奨励
・社内でAWS認定資格取得奨励制度が発足【人材育成の仕組みづくり】【有識者の育成】
・私から上司へハイブリッドクラウドの提案を実施
（開発では社内サーバとの連携が必要。社内ADとの接続が不可欠であるためハイブリッドクラウドの企画立案）
・上司から役員（取締役）に企画説明→承認
・CCoE(推進組織)が立ち上がる【推進組織の立ち上げ】
（構成は、私がリードアーキテクト、部長、他別の部署の責任者）
・自部門にてAWS利用が許可【PoC検証開始】
・AWS利用準備（アカウント管理、ネットワーク設計の検討、利用者への教育）
・社内ネットワークとAWSとの回線が開通 ←今ここ
こうやって振り返ると今年一気に動き始めたなあという印象。
重い腰も上がれば早い。ただ上げるには自分だけでは不可能だったと思います。
やはり、AWSの営業の方をはじめ、私の上司や理解頂いた周りの方々のおかげです。
本当に感謝です。
そして、自分の理想（こうしたい、こうであったらいいのに）を形にするためにちゃんと伝えることが大事だなと感じました。
もちろんそのためにも日々勉強や情報収集が不可欠ですが。
さて、クラウドジャーニーも始まったばかりです。
これから苦難がたくさんありますが、推進チームと一緒に頑張りたいと思います。
ちなみにこんな感じでハイブリッド環境検討構成中です。
社内勉強会「AWSサーバレスAPIハンズオン」開催
社内勉強会にてAWSサーバレスAPIを構築するハンズオンを開催しました。
内容は１時間とという短い時間でしたので、わりと浅い内容ですがSAMについてもちゃんと触れておきました。
ちょうど業務で触れていたこともあり、「AWSで簡単にサーバレスAPI作れるよ」というのを社内の人間に知ってもらいたいという思いで開催しました。
他の支店にも声をかけたところ、数名参加希望があり参加いただけました。本当に嬉しかったです。
AWS自体に今日はあるけど、触ったことがないという人たちも多く、初めてアカウントを作ってもらい実際に動かしてもらいました。
これをきっかけにAWSを好きになって、社内で取り組んでいいくことを期待したいです。
ゲストでお越しいただいたkozakeさんからも、ありがたい発表を頂くことができました。感謝です。
苦労したAWSサーバレスAPI構築物語
しかし、APIゆえにAPIクライアントの事情を組む必要があり、構築の際に苦労した話をしたいと思います。
<前提>
・APIはインターネット公開
・特定のパッケージソフトから利用される
はじめに、APIGatewayにてモックAPIを作成し、OpenAPIのスキーマ（yaml)をクライアント開発チームへ提供し、開発を進めていただいた。（スキーマ駆動開発）
ここまでは良かったのですが、問題が発生。
<当初の構成案>
APIGateway→Lambda
１、TLS対応問題
APIをコールする側のクライアントのアプリケーションがレガシーであり、TLS1.0しか対応できないとのこと。
APIGatewayではTLS1.1以上の対応となっており、頭を悩ませた。
<対応策>
TLS1.0対応のCloudFrontをAPIGatewayのフロントにおいて対応。
２、ペイロードサイズ問題
アップロードされるファイルサイズは10MB以内の前提であった、10MB以内で問題はなかっただが、Lamdaでエラーが発生！
Lamabdaペイロードサイズが6MBであることが判明
<対策>
S3署名URLを発行し、S3に直接PUTしてもらい、それをトリガーにLambdaを起動させる方法に変更
<変更後の構成>
CloudFront→APIGateway→Lambda(S3署名URL発行）
S3→Lambda
いろいろと勉強になりました。
しかし、AWSは問題にぶつかっても何かと別の方法があって助かります。
社内勉強会開催の経緯
なぜ社内でクラウド・マイクロサービスをテーマとした勉強会を開催したのか。
資料では、企業は自社のシステムの技術的負債が足かせとなって利益を上げるための攻めのIT(AIやiot)を推進できないでいるとあった。
技術的負債を抱えたシステムでは情報をうまく活用できないことや、ビジネススピードに機能追加や改修スピードがついていけないことが起因している。
そのため、まずは技術的負債を解消することが、sierである我々の直近の使命だと感じた。
クラウドに関しては、私とインフラ部署のわずかな社員のみだ。
しかし、社内で出来る人が少なく旧式の提案で進めてしまい、せっかくの機会を無駄にしているように思う。
そこで、ここ2年程かけてクラウドやマイクロサービスについてみんなで勉強していこう！という勉強会企画を立ち上げ、社内で承認を得た。
多部署も巻き込んで開催しており、お陰様で参加者も多く会場が満席となるまでになりました。
ゴールは、技術的負債を解消できるエンジニアになること。
勉強だけでなく、参加者にアウトプットしてもらえるよう支援していきたい。
社内勉強会にて発表「AWSCloudformation」
社内勉強会で発表
社内勉強会でAWSCloudformationについて発表しました。
第３回目は会場がついに満席となり、初めて参加する方も半数を超えていた。
これは嬉しい！AWSという人気テーマということもあるけど、続けることは大事だと感じた。しかし、若手の参加率が低いのでそこは課題。
