amareloのブログ(仮)

IT系勉強会で感じた想いや知見をメインに書いていきます。

第19回redmine.tokyo勉強会 参加レポート

11/14(土)Redmine Tokyo に参加しましたので、レポートを書きます!

ただ、今回都合で一部分しか参加できていないこと、YouTubeで後追い視聴をできていないため、 昨日しっかり聞けたところだけでも感想を出したいので、取り急ぎレポートを書きました。 YouTubeで後追い視聴して、追加で概要と感想を書きます(書けたら…)。

目次

イベントページ

redmine.tokyo

YouTube

www.youtube.com

感想(11/15現在)

今回まずは感想から。概要は後述します。

私は個人でPlanioを使っているため、@ryocomoestaさん のPlanio導入事例が一番興味深く聞けました! ヘルプデスク機能があることを全く知らなかったため、Planioの可能性が広がりました。 実業務でPlanioを使えないか、検討したくなりました!

しんやさんのチケットで退職届の話は強烈でしたw 出した人もその勇気は凄いと思いますが、出してはいけない勇気だなぁと思いましたw

パネルディスカッション1では、Redmineを推進するにあたり、

  • 理解を促進する活動
  • どうしたら使えるようになるかの解決思考アプローチ

が大事だということを知りました。これはどんなシステムでも導入初期には大切な活動だと思いますので、 今後の業務で意識したい点だと思いました。

毎回、導入時の方針と運用設計がいかに大事か思い知らされ、勉強になります。 何の挨拶もせずに途中退出して申し訳ない気持ちです。 次回はしっかりと日程調整して腰を据えて参加したいです。

セッション概要

第19回 パネルディスカッション1:続 なぜRedmineによるタスク管理が失敗するか
Redmineによるタスク管理が失敗する理由
  • 完了できないチケットが増えてしまう。
  • 入力されないタスクが多数発生してしまう。
  • チケットには期日を入力しているが守られない。
  • 定期的にタスク棚卸をしなかった。
  • タスク管理のリーダーシップをとる人がいない。
体験①:増えないチケット
  • プロジェクト管理が楽になるという触れ込みのみで導入した。
  • 運用方法が分からず時間を取ることが煩わしくなった。

  • 原因

    • 真の失敗原因は、楽になるという妄想で導入を決定し、使い方のイメージ共有を怠った。
    • チケットの書き方や運用ルールを決めずに運営して、プロセスやルール決定を怠った。
体験②:減らないチケット
  • チケットテンプレートを導入して書かないということはないのだが、どんどんチケットが増えていく。

  • 原因

    • 緩いルールで運営開始してその後のルール改善を怠った。
    • チケットクローズの条件を明確にできていない。
    • チケットの機嫌を過ぎても放置されている。
体験③:Redmine導入に至らなかった
  • ドキュメントがない
  • FAQがない。作成を依頼しても作ってくれない。
  • 問い合わせ記録がない。
体験④:うまくRedmineに導入できた話
  • コロナ禍のリモートワークを機にRedmineに移行。このルールで上手く回している。

    • トラッカーをタスク・QA・サポートの3つに絞る。
    • ステータス、バージョンは管理者にて管理する。
    • チケットの修正、クローズ時は理由を明確にする。
    • チケット完了条件を明確にする。
    • 通知メールに頼らずに毎日ログインして「活動タブ」を見る。
  • 要因

    • 再体現のルールでスタートし、タスク化に注力した。
    • 担当者、期日が明確になった。
    • 「活動タブ」を見ることでキャッチアップが容易になった。
体験⑤:何で乗り気じゃないのかと思ったら
  • Redmine導入したが変化に乗り気でないメンバがいた。

    • ヒアリングしたところ、表示や入力に関する不満が原因。
      • 設定を調整したりプラグイン導入することで不満が解消した。
    • Redmineの基本性能を把握していないメンバがいることが分かった。
  • 成功ポイント

    • 原因追及でなく、解決思考のアプローチ(どうしたら使えるようになるか)で、利用者に寄り添った対応をしたこと。
    • 理解を促進する活動が必要。
体験⑥:何でその機能使っていないの?
  • ExcelでやっていたことをRedmineに移行しただけ。

    • 根拠不明な進捗率管理から工程別の子チケット管理に切り替えた。
    • 1チケット2週間以内のルールを設定、大きなチケットは細分化し登録するようになった。
  • 成功ポイント

    • チケットの粒度や分け方はルールを設定しチームで意識を合わせる。
まとめ
  • RJ2020で出た失敗する要因

    • プロセスやルール
    • ツールの使い方
    • コミュニケーション
    • 心理的安全性
  • 失敗する要因を掘り下げると

    • 問題を他責にしている。
    • 解決志向のアプローチをしていない。
    • 直感的に使いづらいところもある。
      • Redmineを使いづらいという理由でツールに対して他責にして、どうすればよいかが置き去りにされているのでは?
  • どうしたらいい?

    • まずは自ら行動する。
    • 上手くいかせるためには継続的に考える。
    • コミュニティを活用しよう。
LT: Planioと私の604日 @ryocomoestaさん
Planioを選んだ理由
  • メンテナンスしたくない。
  • Planioの方が機能多い。
  • 各種ベンダとの連絡手段として利用した。
    • くたばれPPAP!の精神で。
  • 作業管理を管理する。
    • 時間管理機能でベンダ作業時間を管理。
  • 他社との情報共有
  • ヘルプデスク機能
    • 外部からの問い合わせ先として、ヘルプデスク用メールアドレスを別に用意する。
LT:こんなRedmineの使い方はイヤだ!の紹介 ながやす しんやさん
第4位:全チケット全員ウォッチャー
  • 毎日数千件の通知メールが届く。
  • まともに確認すると一日が終わる。
  • ML代わりに使う人も出る。

  • 対策

    • 必要な人だけをウォッチャーに設定しよう。
    • 全体連絡したいときはニュースを活用しよう。
第3位:半年先のガントチャート
  • PMから「半年先まで1日単位でチケットを作れ」という無慈悲な指示。
  • ちょっとでもスケジュールズレるとチケットの期日を修正しまくる必要がでる。

  • 対策

    • バージョンを活用して大まかなスケジュールを立てる。
    • 近い未来は細かく、遠い未来は大まかに。
第2位:塩漬けチケットの山
  • 1か月更新のないチケットを一気に却下したら凄く怒られた。ただし業務に何の支障もなかった。

  • 対策

    • ちゃんと定期の振り返りで棚卸をしよう。
第1位:退職届
  • これを超えるアクロバティックなチケットの活用方法を知らない。
  • どうやったらクローズできるんだ?
まとめ
  • ちゃんとプラクティスに則って使おう!

全体のまとめ

いつもより雑な感じになってしまい恐縮です。 冒頭書いた通り、YouTubeで後追い視聴して都度追記変更をしていこうと思います!

JAWS-UG CLI専門支部 #170R S3基礎 ライフサイクル 参加レポート

10/29、JAWS-UG CLI専門支部S3基礎 にてライフサイクルのハンズオンを受講しましたので、参加レポートを書いていきます。

目次

イベントページ

jawsug-cli.connpass.com

S3ライフサイクル概要

  • コスト最適にS3を使うためにライフサイクルを設定する。
  • ライフサイクルは、指定したオブジェクトを一定期間経過後に高いストレージクラスから低いクラスへ自動的に破棄または移行させていく仕組み。
  • 高いクラスから低いクラスへのみライフサイクルを設定可能。逆の設定はできない。
  • ストレージクラスは、高い順に、S3・S3 STANDARD_IA・INTELLIGENT_TIERING・ONEZONE_IA・S3 Glacier・S3 Glacier Deep Archive となる。
  • S3 Glacier,S3 Glacier Deep Archive はテープストレージに似ている感じ。
  • S3とS3 Glacier,S3 Glacier Deep Archive のSLAは99.9%
  • S3 Glacier,S3 Glacier Deep Archive は取り出しに時間がかかる。

ハンズオン

手順と構成図

手順一式はこちらです。また、今回のハンズオン構成図は以下の通りです。

http://prototype-handson-cli.s3-website-ap-northeast-1.amazonaws.com/handson_light-aws_service/handson_light-aws_service-s3_lifecycle/_images/handson-basic-lifecycle.png

コマンド

保守担当者想定のIAMユーザ作成に関するコマンド、S3バケット作成、ファイルアップロード部分のコマンドは割愛します。

S3ライフサイクルドキュメントの作成

以下、JSONファイルに書き込みます。

{
  "Rules": [
    {
      "ID": "temporary-objects",
      "Filter": {
        "Prefix": "tmp/"
      },
      "Status": "Enabled",
      "Expiration": {
        "Days": 1
      }
    },
    {
      "ID": "archive-objects",
      "Filter": {
        "Prefix": "archive/"
      },
      "Status": "Enabled",
      "Transitions": [
        {
          "Days": 0,
          "StorageClass": "GLACIER"
        }
      ],
      "Expiration": {
        "Days": 1
      }
    },
    {
      "ID": "short-keep-objects",
      "Filter": {
        "Prefix": "logs/"
      },
      "Status": "Enabled",
      "Transitions": [
        {
          "Days": 30,
          "StorageClass": "STANDARD_IA"
        },
        {
          "Days": 60,
          "StorageClass": "INTELLIGENT_TIERING"
        },
        {
          "Days": 90,
          "StorageClass": "ONEZONE_IA"
        },
        {
          "Days": 120,
          "StorageClass": "GLACIER"
        },
        {
          "Days": 210,
          "StorageClass": "DEEP_ARCHIVE"
        }
      ],
      "Expiration": {
        "Days": 211
      }
    }
  ]
}

このドキュメントで3つのライフサイクルを定義しています。

  • "ID": "temporary-objects"
    • Prefix: "tmp/" に作成したオブジェクトは、作成日から1日経過したら削除される。
  • "ID": "archive-objects"
    • "Prefix": "archive/" のオブジェクトは、オフジェクト作成日から日が変わったらS3 Glacierに移動する。さらにもう1日経過したら削除される。
  • "ID": "short-keep-objects"
    • "Prefix": "logs/" のオブジェクトについて以下のように動作する。
      • 30日経過:STANDARD_IAに移動する。
      • 60日経過:INTELLIGENT_TIERINGに移動する。
      • 90日経過:ONEZONE_IAに移動する。
      • 120日経過:S3 Glacier に移動する。
      • 210日経過:S3 Glacier Deep Archiveに移動する。
      • 211日経過:オブジェクトを削除する。
S3バケットのライフサイクルの作成

`s3api put-bucket-lifecycle' でバケットライフサイクルを設定します。 先に作成したS3ライフサイクルドキュメントを読み込ませます。 エラーが出力されなければOKです。

aws s3api put-bucket-lifecycle-configuration \
--bucket ${S3_BUCKET_NAME} \
--lifecycle-configuration file://${FILE_S3_BUCKET_LIFECYCLE_DOC}

`get-bucket-lifecycle' でS3バケットのライフサイクルが有効であることを確認します。

aws s3api get-bucket-lifecycle \
--bucket ${S3_BUCKET_NAME} \
--query 'Rules[].Status' \
  --output text

今回は3つのライフサイクルを設定したため、Enabled Enabled Enabledと表示されればOKです。

マネジメントコンソール(S3⇒バケット名選択⇒管理⇒ライフサイクルルール)からもライフサイクルを確認します。 以下のように表示されます。

f:id:amarelo-n24:20201102090436p:plain

プレフィックスのライフサイクルをマネジメントコンソールから確認すると、以下のようになります。

①tmp/("ID": "temporary-objects")

f:id:amarelo-n24:20201102091146p:plain

②archive/("ID": "archive-objects")

f:id:amarelo-n24:20201102091436p:plain

③logs/("ID": "short-keep-objects")

f:id:amarelo-n24:20201102091747p:plain f:id:amarelo-n24:20201102091937p:plain

S3オブジェクトのライフサイクル確認

s3api head-object で作成したオブジェクトの有効期限を確認します。

aws s3api head-object \
--bucket ${S3_BUCKET_NAME} \
--key ${S3_OBJECT_KEY} \
--query 'Expiration' \
--output text

①tmp/("ID": "temporary-objects")のライフサイクル

10/30に「tmp/2020-10-30.txt」というオブジェクトを作成しました。

f:id:amarelo-n24:20201103084716p:plain

30日に作成したオブジェクトは31日中有効、11月1日0時になって日が変わった時点で削除されます。 s3api head-object を実行して以下のように表示されることを確認します。

expiry-date="Sun, 01 Nov 2020 00:00:00 GMT", rule-id="temporary-objects"

※補足

Amazon S3 は、ルールに指定された日数をオブジェクトの作成時間に加算し、得られた日時を翌日の午前 00:00 UTC (協定世界時) に丸めることで、時間を算出します(以下公式ドキュメントより抜粋)。

そのため、単純に作成日から指定した日数が経過したら削除したり、クラスを移動したりするわけではありません。この例のように1日経過したら削除とライフサイクル設定した場合は、作成日の次の次の日の午前 00:00 UTCに削除されるという動きをします。

docs.aws.amazon.com

②archive/("ID": "archive-objects")のライフサイクル

10/30に"archive/2020-10-30.txt"というオブジェクトを作成しました。

f:id:amarelo-n24:20201103084847p:plain

30日に作成したオブジェクトは31日にS3 Glacierに移動、11月1日0時になって日が変わった時点で削除されます。 s3api head-object を実行して以下のように表示されることを確認します。

expiry-date="Sun, 01 Nov 2020 00:00:00 GMT", rule-id="archive-objects"

③logs/("ID": "short-keep-objects")のライフサイクル

10月30日に"logs/2020-10-30.log"というオブジェクトを作成しました。

f:id:amarelo-n24:20201103085111p:plain

10月30日に作成したオブジェクトは211日後の2021年5月30日に削除されます。 s3api head-object を実行して以下のように表示されることを確認します。

expiry-date="Sun, 30 May 2021 00:00:00 GMT", rule-id="short-keep-objects"
動作確認

確認が11月2日になってしまいましたが、tmp/とarchive/は削除されたことを確認できました。

※archive/ のオブジェクトがS3 Glacierに移動したことを確認しそびれました。無念…

logs/は有効期限内のため残っています(あと28日待ってはこのブログを公開するのも遅くなってしまいますので、動作確認まではしません)。

f:id:amarelo-n24:20201102090212p:plain

S3ライフサイクル設定の削除

ライフサイクルを削除する場合は、バケット名を指定してs3api delete-bucket-lifecycleを実行します。 エラーが表示されなければOKです。

aws s3api delete-bucket-lifecycle \
--bucket ${S3_BUCKET_NAME}

ライフサイクル設定が無効であることを確認します。

! aws s3api get-bucket-lifecycle-configuration \
--bucket ${S3_BUCKET_NAME}

以下のように表示されればOKです。

An error occurred (NoSuchLifecycleConfiguration) when calling the GetBucketLifecycleConfiguration operation: The lifecycle configuration does not exist

マネジメントコンソール(S3⇒バケット名選択⇒管理⇒ライフサイクルルール)でもライフサイクルが削除されたことが確認できます。

f:id:amarelo-n24:20201103090159p:plain

この後はオブジェクトの削除、S3バケットの削除、IAMユーザ周辺の削除を実施します(手順は割愛します)。

最後に

今回、動作確認の中でS3 Glacierに移動したことを確認できなかったのが心残りです。いったんブログを公開しますが、別途確認したいです。ただ、ライフサイクルの動作確認を実業務でやることになったら、その点を注意しなければならないことを知れて良かったです。実作業で確認漏れしていたら一からやり直しですしね…実際に手を動かして体感することの重要さを改めて思い知りました。

前回のバージョニングも今回のライフサイクルも、S3を適切に運用する上で理解しておくべきことだと思いました。認定試験の勉強で触れて理解したつもりでしたが、使わないと本当に忘れますね。復習できてよかったです!S3以外のサービスも適切な設計や運用を考えられるようになるためにも、できる限りサービスが持っている機能を手を動かして理解した上で使いたいと思いました。

次回もS3を使ったハンズオンで、通知とLambdaの自動実行といった実運用でも良く使いそうなハンズオンなので楽しみです。自分ができることを増やしていきたいです。

※次回のイベントページ

jawsug-cli.connpass.com

JAWS-UG朝会 #14 参加レポート

10/27(火)JAWS-UG朝会 #14に参加しましたので、レポートを書きます。

毎回ラジオ体操から始まる勉強会で今回も楽しみにしていました。が、寝坊で7:30までに間に合わなく、ラジオ体操はできませんでした…

目次

イベントページ

jawsug-asa.connpass.com

セッションとLT

AWSコスト最適化のポイント~ここまでできるコスト削減~ 小寺 加奈子さん
資料

www.slideshare.net

概要
  • コスト削減を実現するためにリザーブインスタンスやSavings Plansを利用する。
  • リザーブインスタンスにはStandard(完全前払い)とConvertible(一部前払い)がある(EC2のみ)。
    • サイズの変更ができるが、予約期間中に別のリージョンに変更できない。
  • オンデマンドと比較した削減額は、 EC2 Standardが最大72%、Convertibleは最大66% (リージョンによっても割引額は異なる)
  • Savings Plansには、Compute Saving Plans (全額前払い)とEC2 Instance Savings Plans(一部前払いで最大72%削減)がある。
  • Compute Savings Plans はリージョン、AZ、インスタンスファミリー・サイズ、OS、テナンシーに関係なく自動的に適用される。

  • コスト削減した利用料をどうモニタリングするか?

    • Cost Explolor で料金確認
    • Budgets で予算超過したらメールやSlackで通知
    • Budgets Action で予算が閾値を超えた時にEC2を起動できないようにする。
    • 不正利用による急激な利用料増加を検知する。
動画配信 × お買い物 × サーバレス 三浦 一樹さん
資料

speakerdeck.com

概要
  • 動画配信とグッズ販売のイベントをすることになり、サーバレスで構築した。
  • 動画配信の安定性と当日何もしなくても良いように、AWS Elemental MediaLinkを購入した。

    • AWS Elemental MediaLinkについてこちら
    • 995ドル(10万円くらい)で買える。
    • アカウント紐づけて刺すだけでAWS Elemental MediaLiveと連携でき、マネージドコンソールから死活監視をできる。
    • SINGLE_PIPELINEしか設定できないので、AWS Elemental MediaLiveが2つ必要。
  • ショッピング部分はShopifyがめちゃ便利だった。

  • タイムセールと時間限定商品に対応させるために、GraphQLとAppSyncを使ってリアルタイム更新できるようにした。
    • リロードなし、イベント進行に合わせたリアルタイム更新ができた!
CloudEndureでVPSからAWSへ移行 小倉 大さん
資料

www.slideshare.net

概要
  • CloudEndureとは

    • AWSへの移行を無料で簡単に出来るツール
    • 移行元は物理と仮想環境に対応
  • さくらのVPSにあるWordPress(CentOS5)の環境を移行した。1時間半くらいかかった。

  • 手順はBlackbeltの資料に詳しく書いてある。
Organization周りの機能 富松 広太さん
資料

www.slideshare.net

概要
  • Organizationsと連携可能なサービス

    • CloudFormation Stacksets
    • CloudTrail
    • AWS Config
    • 他にもあるが今回はなすのは上記3つについて
  • CloudFormation Stacksets

    • 特定のOUを指定してCloudFormationを実行
    • 特定OUへのアカウント紐づけに連動したCloudFormation自動適用
  • CloudTrail

    • 親アカウントで一度設定すれば、子アカウントの個別設定が不要になる。
    • 親アカウントのS3に子アカウントのログが自動収集される。
    • 親アカウント以外の収集先は選択不可
    • 全アカウント有効・無効のみ変更可能
  • AWS Config

    • 親アカウントで一度設定すれば、各子アカウントでの個別設定が不要
    • config の情報が親アカウントに自動収集される
    • 親アカウントで子アカウントのリソースを閲覧可能
    • 組織へのルール一括適用・管理も可能
Lightsailでワンコイン開発環境をつくる 波田野 裕一さん
資料

speakerdeck.com

概要
  • 10/19にCloud9でLightsailを利用可能になった。
  • Lightsailは月額課金でEC2よりかなり安い。
  • インスタンスイメージをEC2にエクスポート可能
  • RDSやALB、CloudFrontに相当するオプションがあり拡張性や移植性がある。
  • APICLIからほぼすべての操作を操作できる
  • VPCは使えない
  • インスタンスプロファイルは使えない
  • ブループリント(AMI相当)は作れない
  • AutoScallingは使えない
  • ドメインサブドメインを無料でホストできる(Route53相当)。

  • ストレージとデータ転送料込みで月額約366円(ワンコイン未満)で開発環境構築が可能に。

    • インフラエンジニアもアプリをかけるようになろう!

最後に

やはり朝から勉強会やるとそのまま仕事には入れるので、気持ちが引き締まりますね! また、朝仕事する前の勉強会の方が、その日の仕事にもあまり左右されず(突発の仕事で参加できなくなったってことになりにくい)、 家族にもあまり気兼ねせずに参加できて良いと思います(ラジオ体操全力でやると逆に家族に迷惑かけるかもですが…)。

LightsailでEC2よりもコストの心配を少なく環境構築できるのは魅力的だなぁと思いました。 前々からコードをちゃんと書けるようになりたいと考えていたので、これを機に自分もLightsail使ってみたくなりました。 30 日間無料 (750 時間/月)みたいなので、時間の都合をつけてとにかくやってみようと思います!

オンラインでMicrosoft Azure Fundamentals(AZ-900)を受験しました

先日、Microsoft Azure Fundamentals(AZ-900)を受験しました。 このご時世ですので、試験会場に行くよりはオンラインで受験できるならば、ということでオンラインで受験しました。 これからオンライン受験する方もたくさんいると思いますので、少しでも参考になればと思い、 オンライン受験したこと、自分がやった対策について書こうと思います。

※2020年10月時点での情報です。

目次

Microsoft Azure Fundamentals(AZ-900)とは

Azure Fundamentals (AZ-900)は、クラウドの概念、 Azure サービス、 Azure ワークロード、 Azure のセキュリティとプライバシー、 Azure の価格とサポートに関する知識を証明するための試験です。

docs.microsoft.com

受験のキッカケ

私は、AWS認定を2つ(クラウドラクティショナー、ソリューションアーキテクトアソシエイト)を取得しています。 次のAWS認定受験を何にするか迷っていたところでしたが、Azureについても基礎的なことは知っておきたい、AWSとの違いを知りたいと思い、勉強することにしました。

試験対策

Microsoft Azure Virtual Training Day: Fundamentals受講

Microsoftが主催するAZ-900受験バウチャー付きのセミナーに参加しました。 2日間できる限りメモを取り集中して受講しました。 2日間受講したら、AZ-900無料受験の権利を得ることができます。

今は開催されているのかは分かりませんが、見つけたらとにかく申し込んで受講してみるのが良いと思います。また、無料受験の権利がいつまで有効かもわかりませんが、受講したらなるたけ早めに受験申し込みすることをお勧めします。 私は7月末に受講して10月前半に受験申し込みと3か月弱開いてしまいましたが、無料受験申し込みできました。

書籍

「合格対策 Microsoft認定 AZ-900:Microsoft Azure Fundamentalsテキスト&問題集」

今のところこれしかありません。AZ-900受験の際はこれを買いましょう! とても良くまとめられていて、要領を抑えるには適切だと思います。 模擬試験1回分も収録されているため、予行演習としても最適です!

セミナー受講後はこれとMicrosoft Learnを合わせて取り組みました。

Microsoft Learn

docs.microsoft.com

Web上でMicrosoft社のサービスに係る学習コンテンツです。 AZ-900で扱うことには一通り触れられています。 また、サンドボックス環境を使ったハンズオンもありますので、Azure使ったことない人でも気軽に使えて理解が深まると思います。

Microsoft公式ドキュメントを読む

参考書とLearnでは不十分かなと思ったサービスについては、深堀りするために読みました。 AWSの勉強もそうですが、Azureでも公式のドキュメントを読むのは重要です。

オンライン受験申し込み

ピアソン(Pearson VUE)で申し込み可能ですが申し込み前に、

  • 誰も入ってこれないようにできる部屋があること
  • 手の届くところに本と筆記用具を置ける場所がないこと
  • 十分な帯域のネットワーク環境(LANは無線より有線の方が望ましい。モバイルWifiはNG)
  • Webカメラとマイクが動作可能であること

を確認すべきです。 Webマイクとカメラは申込時に簡易的なシステムチェックがありますので、それで確認すればわかります。 部屋が用意できない等、上記ポイントの確保が怪しいと思ったら、オンライン受験を断念した方が良いかもしれません。当日受験できないことになっても返金されないためです。

自分は変な指摘をされる隙を作りたくなかったので、部屋にあるすべての筆記用具と書籍類、プリンタなどPC周辺機器はすべてウォークインクローゼットに疎開させました。そこまで徹底する必要はなかったかもしれませんが、試験直前にトラブって焦るのも嫌だったので…

なお、2020年10月現在、受験日は平日しか指定できません。仕事の調整は必須です。 私は受験費免除のバウチャーがあったのでクレカ番号の入力はありませんでしたが、通常ならば支払いにクレカが必要です。

当日の手続き

事前に身分証明書を用意します。国が発行した証明書が必要です。免許証かパスポートのどちらか1つがあればOKです。

ピアソンの試験予約ページより30分くらい前から試験準備可能です。 まずは、

  • 受験PC周りを写真撮ってアップ
  • 身分証明書(免許証かパスポート)を写真撮ってアップ
  • PCを持って部屋360°Webカメラで映す

ことを要求されます。 焦ることのないように、試験開始前の手続きは試験30分前から余裕持って実施することをお勧めします。私も30分くらい前から開始しましたが、写真撮ってアップするところで手間取り、15分くらいかかってしまいました。

試験管とのやり取りは音声ではなく、チャットでの会話となります。日本語対応可能なため、特に不便はありませんでした。 問題なければ時間まで待機し、時間になったら試験開始となります。

試験結果

700点合格のところ、760点合格でした!

嬉しかったけど、結構ギリでヒヤッとしました…(汗)

感想

オンライン受験について

受験した日は家族が仕事や学校に行っていて誰もいなかったので、邪魔が入らずにスムーズに受験できました。 試験途中、外で工事をしていた音が入ってきたのにはちょっと気をそらされましたが、概ね良好に受験できたかなと思っています。 合格が分かりWebカメラの監視が終了してすぐに「よっしゃぁーーー!」と叫びましたw 嬉しくても悲しくても、試験結果がわかってから人目を気にせず感情をあらわにできるのもいいところですねwww

受験結果について

合格したことは嬉しいけど、SAAやプラクティショナーの時と比べて自信があったのに合格ラインギリだったので複雑な気持ちです。 勉強して理解していたつもりでしたが、やはり実践に勝るものはありません。 出来れば30日間の無料期間を有効活用して理解を深めた方がよいです。 上位資格を狙う時に使いたいと思い、今回は無料期間利用を見送りましたが、ケチってはいけないですね…

Azureも試験だけで終わらず、今後も勉強し続けたいです!

最後に

コロナ禍の状況で試験会場に行くのも憚れる時代ですが、受験したい認定試験がオンライン化しているのは嬉しい限りです。 オンラインで安心して資格試験を受験できる環境がもっと広まると良いなぁと今回の受験で思いました。今後も活用していきたいです。

オンライン受験も人によって向き不向き、環境による可否はあると思いますので、「お勧めします」とは言いづらいです。しかし、

  • リモートワークが好き、または許容できている
  • 試験会場まで行くのが面倒
  • 部屋が片付いている(or 片付けることが面倒ではない)
  • コロナ感染が不安

という人は、オンライン受験を検討してみても良いと思います!!

はじめての〇〇 超LT会- vol.1 #ultralt で超LTしました

10/14 「はじめての〇〇 超LT会- vol.1 #ultralt」に登壇してきました。 久々の登壇でしたが無事終了しました!取り急ぎ感想を書きます。

目次

イベントページと概要

こちらです。1人1分の超ライトニングトークで、はじめての経験をネタに31人が登壇しました。

rakus.connpass.com

登壇資料

元ネタは以前ブログにも書いたトラックボールデビューした話です。今年はじめての経験をして印象に残っているのがこれだったので。

speakerdeck.com

感想

自分の登壇について

冒頭書いた通り久々の登壇でした(今年の3月にインフラ勉強会でLT登壇して以来)ので、練習でも詰まったり1分オーバーしたりと…ブランクを感じました(汗) LTは何とか1分で終わることができました。1分とはいえ時間を貰って話すわけですし、ちゃんと練習しておいて良かったです。練習大事!!

自分の番になりZoomの画面共有に若干もたつきました。Zoomでオンラインイベントに参加するなど、参加者側として使うのは多かったですが、 実際に画面共有したのはじめてでした。何でもやってみないと分かりませんね…でも、今回それを経験できたのはホント良かったです。

登壇前はトラックボールの話だとインパクト薄いかな~と思いましたが、意外にも休憩時間中のフリートークでもトラックボールのことが話題になってたところを見た時は、やはり話してよかったと思いました! また、SW-M570は名器ということもわかりました。やはり使っている人多いですね。

他の方々のLTを聞いて

1分のLTは緊張感があって面白いですが、他の方の登壇もあっという間に終わってしまうので、聞く方も集中して聞く必要があります。 聞く方に集中しすぎるとツイート実況できなかったり、メモできなかったり… そのため、全登壇者の感想を書くことはできそうもないです。スイマセン… 一部登壇者のお話を聞いてから思ったことを簡単に書かせていただきます。

  • 1分のLTでももう少し資料枚数作った方が良かったかな?(全体を通して。自分の資料は2ページだったのでw)
  • WSL1とWSL2の違いはちゃんと抑えよう(@YKanoh65さん はじめてのWSL2より)
  • GB studio面白そう。ゲームボーイなつかしい!(@rom1000_yksbpnさん 俺の作ったゲームが、こんなにNoCodeなわけがないより)
  • カイゼンジャーニーをもう一度読みたくなってきた(@saya1001kirinnさん はじめてのスクラムより)
  • 自分もポートフォリオサイト作って公開したい(uni__82さん はじめてのポートフォリオ公開より)
  • エンジニアの成長を応援する本2の感想書こう!自分も寄稿したし。(@maiameaさん はじめての寄稿より)
  • 個人開発もやりたい!(@itizawa_pen はじめての本格的個人開発より)
  • 動画での登壇は斬新!!(@sogaoh さん はじめてのe-Taxより)
  • ループさせたときは焦るのわかる!あと、顧客と仲良くなることと巧みな話術は大事w(@Infra_さん はじめてのループより)

雑な感想かもしれません。本当に申し訳ありません(汗)

最後に

やはりLTは楽しいですね。勉強会に自発的に参加しているという気持ちになれます。 そういえば、コロナ禍で勉強会がオンラインになったので登壇する機会はたくさんあったはずなのに、なぜ半年以上も登壇しなかったのか? オンライン登壇はインフラ勉強会でやってたから躊躇するものはなかったはずだけど… ともかく、これでオンライン勉強会の登壇(顔出し)の実績を作れたので、また積極的にLT登壇やっていきたいです!

LT登壇できて良かったです。主催のラクス様、ありがとうございました!!

JAWS-UG CLI専門支部 #169R S3基礎 バージョニング 参加レポート

10/8、JAWS-UG CLI専門支部にてS3バージョニングのハンズオンを受講しましたので、参加レポートを書いていきます。

目次

イベントページ

jawsug-cli.connpass.com

S3概要

S3については前回も触れましたので、今回はバージョニングに関係するところを書きます。

  • S3全体が名前空間のため、グローバルユニーク
  • オブジェクトの名前スキーマ
  • バージョニング使うか?
    • バケットの中身は使い捨てで、バケットの外でバージョン管理をする(バージョニングを使わない)。
    • または、バケットの中身をマスターとしてバケットでバージョン管理をする。
  • 以下はバージョニングを利用する機能であり、ユーザが勝手に上書きや削除等をできないようにする。監査に使える。
    • オブジェクトロック
      • リテンションモード
      • リーガルホールド
  • gitのように差分を保管しているわけではないので、バージョン指定で削除しても、他のバージョンには何の影響もない。

ハンズオン

手順と構成図

手順一式はこちらです。また、今回のハンズオン構成図は以下の通りです。

http://prototype-handson-cli.s3-website-ap-northeast-1.amazonaws.com/handson_light-aws_service/handson_light-aws_service-s3_versioning/_images/handson-basic-versioning.png

コマンド

前回同様、保守担当者想定のIAMユーザ作成に関するコマンドは割愛します。

バージョン管理用S3バケットの構築

まずは、S3バケットを作成します。

aws s3api create-bucket \
--bucket ${S3_BUCKET_NAME} \
--create-bucket-configuration "LocationConstraint=${S3_BUCKET_LOCATION}"

以下の通り表示されたらOKです。

{
    "Location": "http://handson-cli-s3-versioning-XXXXXXXXXXXX.s3.amazonaws.com/"
}

作成確認は、S3バケット名${S3_BUCKET_NAME}が存在することを確認します。 作成したバケット名が表示されればOKです。

aws s3api list-buckets --query "Buckets[?Name == \`${S3_BUCKET_NAME}\`].Name" \
--output text

S3バケット名${S3_BUCKET_NAME}が指定のリージョンにあることを確認します。 作成時に指定したリージョン(今回は東京リージョン)が表示されれば、OKです。

aws s3api get-bucket-location \
--bucket ${S3_BUCKET_NAME} \
--output text
IAMポリシーの作成とIAMグループへのアタッチ

S3バケットにアクセスするためにポリシーを作成します。 IAMユーザ作成関連のコマンドは割愛しましたが、今回からポリシ作成とアタッチの手順が変わりましたので、復習のためにこの部分は書きます。

iam create-policy でIAMポリシーパスを指定してIAMポリシーを作成します。 エラーが表示されなければOKです。

aws iam create-policy \
--policy-name ${IAM_POLICY_NAME} \
--path ${IAM_POLICY_PATH} \
--policy-document file://${FILE_IAM_POLICY_DOC} \
--description "${IAM_POLICY_DESCRIPTION}"

iam list-policies でポリシの存在確認をします。 作成したポリシ名が表示されればOKです。

aws iam list-policies \
--scope Local \
--path-prefix "${IAM_POLICY_PATH}" \
--max-item 1000 \
--query "Policies[?PolicyName == \`${IAM_POLICY_NAME}\`].PolicyName" \
--output text                           

ポリシを設定済のグループにアタッチします。 エラーが表示されなければOKです。

aws iam attach-group-policy \
--group-name ${IAM_GROUP_NAME} \
--policy-arn ${IAM_POLICY_ARN}

アタッチされたことを、iam list-attached-group-poilcies で確認します。 作成したポリシ名が表示されればOKです。

aws iam list-attached-group-policies \
--group-name ${IAM_GROUP_NAME} \
--query "AttachedPolicies[?PolicyArn == \`${IAM_POLICY_ARN}\`].PolicyName" \                  
--output text

S3バケットにアクセスします。0が返されればOKです。

aws s3 ls s3://${S3_BUCKET_NAME} > /dev/null 2>&1 
echo $?

最後に環境変数を削除して、プロファイルの権限を無効にします。

export -n AWS_DEFAULT_PROFILE
S3バケットのバージョニング有効化

s3api put-bucket-versioning でS3バケットのバージョニングを有効(Enabled)にします。 エラーが返されなけばOKです。

aws s3api put-bucket-versioning \
--bucket ${S3_BUCKET_NAME} \
--versioning-configuration Status=Enabled

s3api get-bucket-versioning でバージョニングが有効であることを確認します。 Enabledと表示されればOKです。

aws s3api get-bucket-versioning \
--bucket ${S3_BUCKET_NAME} \
--query 'Status' \
--output text

マネージドコンソールを確認すると、対象のS3バケットのプロパティにて、バージョニングが有効(紫色のチェックが入っている)になっていることが確認できます。

f:id:amarelo-n24:20201010173119p:plain

動作確認

ここから動作確認していきます。 まずはS3バケットにオブジェクトをアップロードします。

aws s3 cp ${FILE_LOCAL} s3://${S3_BUCKET_NAME}/${S3_OBJECT_KEY}

以下のように表示されたらOKです。

upload: ${HOME}/environment/local-handson-cli-s3/handson-cli-s3.txt to s3://handson-cli-s3.txt

S3バケットにオブジェクトが存在することを確認します。 0と表示されます。

aws s3 ls s3://${S3_BUCKET_NAME}/${S3_OBJECT_KEY} \
  > /dev/null 2>&1
echo $?

アップロードしたファイルを更新後、s3 cpコマンドで再度アップロードします(コマンドは割愛)。

次にバージョンを指定してダウンロードします。 オブジェクトのバージョンIDを取得します。 文字列が表示されたらOKです。

S3_OBJECT_VERSION_ID=$( \
aws s3api list-object-versions \
--bucket ${S3_BUCKET_NAME} \
--prefix ${S3_OBJECT_KEY} \
--query "reverse(sort_by(Versions, &LastModified))["${COUNT_OLDER}"].VersionId" \
--output text \
) \
&& echo ${S3_OBJECT_VERSION_ID}

指定したバージョンのオブジェクトをダウンロードします。

aws s3api get-object \
--bucket ${S3_BUCKET_NAME} \
--key ${S3_OBJECT_KEY} \
${FILE_S3_OBJECT_OUTPUT} \
--version-id ${S3_OBJECT_VERSION_ID}

以下のように表示されるとOKです。

{
    "AcceptRanges": "bytes",
    "LastModified": "Thu, 08 Oct 2020 10:05:16 GMT",
    "ContentLength": 7,
    "ETag": "\"xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\"",
    "VersionId": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
    "ContentType": "text/plain",
    "Metadata": {}
}

バージョンを指定して削除します(手順では最新バージョン(0)を削除しました)。

aws s3api delete-object \
--bucket ${S3_BUCKET_NAME} \
--key ${S3_OBJECT_KEY} \
--version-id ${S3_OBJECT_VERSION_ID}

以下のように表示されればOKです。

※yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyに${S3_OBJECT_VERSION_ID}の値が表示されます。

{
  "VersionId": "yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy"
}

指定の世代のバージョンが存在しないことを確認します。 s3api list-object-versions を入力して、何も表示されなければOKです。

aws s3api list-object-versions \
--bucket ${S3_BUCKET_NAME} \
--prefix ${S3_OBJECT_KEY} \
--query "Versions[?VersionId == \`${S3_OBJECT_VERSION_ID}\`].VersionId" \
--output text

バージョニングの動作確認をしたら、すべてのバージョンを削除します。 すべてのバージョンを削除するには、バケットに残っているオブジェクトのバージョンを取得し、for文でバージョン数分のs3api delete-object を実行します。

for i in $(
  aws s3api list-object-versions \
    --bucket ${S3_BUCKET_NAME} \
    --prefix ${S3_OBJECT_KEY} \
    --query "Versions[].VersionId" \
    --output text \
); do
  aws s3api delete-object \
    --bucket ${S3_BUCKET_NAME} \
    --key ${S3_OBJECT_KEY} \
    --version-id ${i}
done

オブジェクトにバージョンが存在しないことを確認します。

! aws s3api list-object-versions \
--bucket ${S3_BUCKET_NAME} \
--prefix ${S3_OBJECT_KEY} \
--query "length(Versions)"

以下のように表示されたらOKです。

In function length(), invalid type for value: None, expected one of: ['string', 'array', 'object'], received: "null"
バージョニングの無効化

バージョニング有効化にした時と同様、`s3api put-bucket-versioning'でバージョニングを無効化(Suspended)にします。

aws s3api put-bucket-versioning \
--bucket ${S3_BUCKET_NAME} \
--versioning-configuration Status=Suspended

s3api get-bucket-versioningバケットの状態を確認します。Suspendedと表示されればOKです。

aws s3api get-bucket-versioning \
--bucket ${S3_BUCKET_NAME} \
--query 'Status' \
--output text

また、マネージドコンソールを確認すると、対象のS3バケットのプロパティにてバージョニングが有効(紫色のチェック)だったのが、無効(チェックの色が灰色)になっていることが確認できます。

f:id:amarelo-n24:20201010173500p:plain

バージョン管理用S3バケットの破棄

s3api delete-bucket でS3バケットを削除します。

aws s3api delete-bucket --bucket ${S3_BUCKET_NAME}

削除したS3バケットが存在しないことを確認します。

aws s3api list-buckets \
--query "Buckets[?Name == \`${S3_BUCKET_NAME}\`].Name" \
--output text

手順は割愛しますが、保守担当者想定のIAMユーザを始めアクセスキー、IAMグループを削除して完了です。

最後に

バージョニングは、S3オブジェクトの変更履歴を厳密に管理する目的があるならば使えるかもしれませんが、そうでもなければあまり使わないかなと思いました。しかし、このような仕組みがあるということをちゃんと覚えておいた方が、自分の引き出しが増えて良いと思いました。バージョニングについてはSAAの勉強時にも触れましたが、今回のハンズオンを受けるまではそのような機能があったことを忘れていました(汗)理解していたつもりになっていたなぁと思い反省しています。

CLI専門支部AWSの勉強を続けてそろそろ半年。こうやって続けられているのは、やはり「AWSが好きなのかな?」「CLIが好きなのかな?」と思ってきました。そろそろ、独自てAWSを使った何かを実現して、LT登壇ネタ、ブログのネタにできればなぁと思います。

JAWS-UG朝会 #13 参加レポート

9/28(月)JAWS-UG朝会に参加しましたので、参加レポートを書きます。

目次

イベントページ

jawsug-asa.connpass.com

セッションとLT

ラジオ体操

まずはいつも通り恒例のラジオ体操から始まりました。朝は体を動かすの大事ですね! ちゃんとPCの前でラジオ体操第一やりました!!

AWS Single Sign-Onのお話 鄭昌浩さん

prezi.com

  • AWS SSOとは2020年9月3日に東京リージョンでGAされたサービス
  • Organizationsのサブ機能的な位置づけ
  • SAML2.0準拠のクラウドアプリケーション(Datadog、GitHubなど)にシングルサインオンが可能
  • AWS Organizations マルチアカウントにシングルサインオン。それぞれのコンソールにログオン可能
    • マルチアカウントのアクセス管理、サインインが容易に
  • Organizationsの利用が前提で全機能有効化が必須
    • 有効後に作成されたアカウントでは承認処理が不要
  • AWS SSOの設定
    • MFAとポータルとなるURLの設定
    • アクセス権限セットの設定
    • アプリケーションの設定
    • グループとユーザの作成(IAMユーザとは全く別のもの)
  • アカウントを本番系、開発系で完全に分離して誤アクセス予防するなどの用途に
  • Organizationsを使っている人は使ってみては?

最後に現職を今月末(明後日)で退職して、10月からAWS社員に転職が決まっているとのこと。 おめでとうございます!!ビックリしてここまでの内容が吹っ飛びそうでしたw

Cognito、Azure ADと仲良くしてみた 近藤 恭史さん

www.slideshare.net

  • Cognito

    • Web、モバイルアプリケーション向けのユーザ認証機能を提供するサービス
    • Cognito User Pool、Cognito ID Pool、Cognito Syncがある。
      • Cognito User Poolは、ユーザ認証と管理を行う。ldp連携も可能。
  • Azure ADとは

    • Microsoftが提供しているクラウド認証サービス
    • Microsoft365を使っていると裏で動いている
  • 業務システムごとにサインイン、ユーザー管理するのは面倒

  • サインインの画面を準備するのは手間
    • Amplifyで一から作るより楽にできるけど、日本語化など手を加えることが必要になる。
  • CognitoとAzure ADで仲よくすることで解決
    • User Pool とAzure ADをSAML2.0で連携してAzure ADでユーザ管理
ClientvpnとPrivate CA 富松 広太さん

www.slideshare.net

  • ClientVPN

    • クライアント端末からVPN接続
    • AWSのネットワークに接続
    • 認証はAD認証、SAML認証、相互認証(証明書による管理なので個別に認証局の管理が必要)
  • 相互認証の証明書管理のためにAWS ACM Private CAを使ってみた。

    • 証明書の運用(ユーザ作成、失効)をできる。
    • S3に失効リストが自動作成される。
    • 証明書関連の操作に一部CLISDKが必要
    • サーバ管理不要だがかなり高額(400ドルくらい)
Permission Boundary をやっと理解できたので誰か聞いてくれ(雑) 大竹 孝昌さん

www.slideshare.net

  • Permission Boundaryはアカウント内から制御する。OrganizationsのSCPはアカウントの外から制御する。
  • 権限の委任はしたいけど特定の操作は制限したい場合にPermission Boundaryを使用。
  • ここまで条件がそろってる場合は不要
    • IAM権限を持つ人に十分なスキルがある。
    • チーム内が比較的小規模である。
    • チーム内の信頼関係が十分構築されている。
  • IAMをマスターすることは良いAWSライフを送れるための第一歩
AWSでたくさんお金を使っちゃった話 高原未菜さん

www.slideshare.net

  • Amazon様に150万円/月もの課金をしてしまった。
  • 性能測定のためにRDS/Auroraに約15TBの料金がかかっていた。

    • インスタンス停止時もストレージ料が課金されていた。
    • 停止していても7日間経過すると自動起動されるため、起動されていた。
  • 改善策

    • 性能測定データはスナップショットを作成しS3に保管する。
    • 性能測定以外はRDSをインスタンスごと削除
  • 節約術

    • DynamoDBのデフォルト設定でテーブルを作ると、未使用でも1テーブル400円くらいかかる。
    • オンデマンドにすると未使用の場合でも0円になる。未使用テーブルが8つあったので、3,000円節約できた。

150万円、額の大きさにただただ驚きでした…PoCやハンズオンが終わって作った環境を使う見込みがないならば、とにかく削除した方がいいと改めて思いました。私は個人アカウントなので、これと同じことやったらと思うと恐ろしい…

最後に

テーマを設けていなかったのにほとんど認証認可の話になったのは、それだけセキュリティ、特に認証認可に関心が強い方が多いからだと思いました。サービスを展開する上でとにかく守らなければならないところですが、今日お話を聞いていて理解不十分なことがわかりました。もう一度、SAML、SSOなど認証認可周りを勉強したくなりました。

セキュリティを勉強しなおして、AWS 認定セキュリティ-専門知識」 の取得を目指そう!その前にDVASOAか…