sorta kinda...

主にAWS関連ですが、これに限らずいろいろ勉強したことや思ったことを書いていきます。

chillSAP第2回イベント『SAPなんでもライトニングトーク祭』に参加してきました!

お祭りは好きですか?私は好きです。那須です。

6/19(水) に「chillSAP第2回イベント『SAPなんでもライトニングトーク祭』」というイベントお祭りに参加してきました。 ちゃっかり LT もやってきました。 今日はそのレポート的なものを書きますね。

techplay.jp

 

chillSAPとは?

SAP関連情報をソーシャルメディア(Twitter, Facebook)やブログ等で発信しているメンバーが集まったコミュニティ ということになってます。 私は SAP のことはほとんど発信してない気もしますが、気づいたら参加していました。

もともと Solution Manager って製品のコンサルティングをやっていたので、ABAP とか Java とかはわかりますが、SAP でどんなことを他社や他者がやっているのかは全く知りませんでしたし、知ろうとも思っていませんでした(そう、昨年まではね
なので、このコミュニティから出てくる情報って自分的にはすごく新鮮で面白かったんですよね。 やっぱ何かをギブされるとギブ仕返したくなるのが私です。 今回もそうですが、これからも一生懸命何をギブし返そうか考えてますよ。

 

どんなお祭りだったの?

すでに他の方が書いてくれてますので、リンク先を見てください。 決して楽をしているわけではありませんよw

togetter.com

www.sapsumikko.jp

個人の感覚ですが、参加者の半数以上はアプリの(業務設計するような)方でした。 なので、LINE ?経由で購買伝票とかなんとか伝票とかを登録してみたデモが見れたり、SAP Cloud Platform をベースにアプリケーション観点の話が多かったですが、普段の仕事ではこんな話を聞くことはほぼ皆無なので、こういうことが普段の業務では行われてるんだろうなーと想像しながら聞いてましたね。

だっふんだ!とかも実際の業務では使わないと思われるものの、斬新なアイデアやこれもしかして役に立つんじゃね?みたいなアイデアって技術の無駄遣いからしか生まれないんですよね。 あとは毎日毎日考え抜いた人にしか生まれてこないって感じかな。 今までの人生でこういう経験をしてきたからこそ、今回のお祭りは楽しく感じたしもっとはっちゃける人が出てくると面白いなと思いました。

ちなみに私は構成としては無駄と思われるものでも、運用の観点で見るとあった方がいい構成を考えて発表しました。 単純に IP アドレスに依存する運用をなくしたいだけです。 Web システム等だと当たり前ですが SAP システムではそうでもない雰囲気なので、こうなればいいなー

speakerdeck.com

 

コミュニティやイベントに参加する価値とは?

話は変わりますが、私も昔はイベントとか勉強会とかコミュニティに属するとか、全く興味なかったです。 何が楽しいんだろう?本当に勉強になるのかな?いつ言っても同じメンバーばっかりで新規参加者は楽しめないんじゃないかな? って気持ちしかなかったので、行ってもせいぜい年 1 回くらいって感じでした。 それが今や年 4 回は LT で喋ったり登壇したりするようになりました。 何が私を変えたんでしょうか?

ここで質問です。
他社や他者が一体なにをやっているのか知っていますか?
もし他の方が何をやってるのか知ろうともしていなかったことに今気づいたなら、今日からちょっとだけでいいのでアンテナをはって知ろうとしてみてください。

自分が今持ってる価値や判断基準とかって、その人と同じですか?違いますか?
同じだったらちょっと話してみてあわよくば仲良くなりたいと思いませんか?
もし違ってたら、どういう経緯でそういう考えを持っているのかちょっと知りたくないですか?

その思いを持って外に飛び出してみてください。 それが外のモノサシを知るきっかけになります。

www.itmedia.co.jp

外のモノサシの定義はもしかしたら人それぞれ違うかもしれませんし、私だけ間違って解釈してるかもしれません。 でも一旦はそれでいいじゃないですか。 だって人間だもの。所詮は人生の 1 ステップです。 自分の外の世界で何が起こっているのかを知ることって、回り回って自分にいろんな気付きを与えてくれますよ。

 

おわりに

ここまで書いてみたものの全然レポートっぽくないなーと思いましたが、まあ自分のブログなんで自分の意見は書くべきかなと思って書いてみたらこんな感じになりました。

  • SAP の技術情報とかって書いたらダメなんかな?
  • Note とかも S ユーザ登録しないと見れないからあんまり書くべきじゃないんかな?
  • でも英語で検索すると個人がブログでガンガン書いてるし Note の内容のまんまの記事もあるし、案外書いても大丈夫なのでは?
  • 書いちゃダメって思ってるの、もしかして自分たちだけなのでは???

という感想しかないので、chillSAP の皆さんと一緒に SAP の情報を日本語でバンバン出していくと日本のユーザさんが喜ぶんじゃないかなって思います。 それが JSUG だったりするのかもしれませんが、まあ別にかぶってもいいんじゃないかなー、なーんて。

RDS for Oracle で Data Pump による運用の形を考えてみた

シンプルな運用が大好きです、那須です。

RDS は皆さん使ってますか? OS 周りのことは気にせずに運用できるのがすごくいいですよね! そんな RDS ですが、バックアップはスナップショットがあるのであんまり自分で気にすることはありません。 ですがスナップショットからリストアすると新しいインスタンスができる形になるので、オンプレでの DB 運用を想像してるといろんなことを気にしないといけないですよね? DNS とか。 今回はそんな RDS のバックアップリストアのお話です(すいません、スナップショットの話はこれで終わりですw

 

RDS for Oracle のバックアップリストア運用パターン

RDS for Oracle では Data Pump を使ってデータのエクスポート/インポートができます。 訳あって既存の Data Pump でのバックアップリストア運用をしたくて、ちょっと調べてみました。 ちなみに RDS for Oracle へのデータインポートは↓このドキュメントが参考になりますよ。

docs.aws.amazon.com

手段は固まったのであとはどうバックアップデータを運用するかですが、RDS では下記のような形になると思います。 ダンプファイルは最終的には S3 に保存したいというのが要件です。

f:id:nasrinjp1:20190617204205p:plain

  1. エクスポート実行したら S3 にダンプファイルコピー
  2. エクスポート実行したらダンプファイルを EBS ボリュームに保存しそのボリュームのスナップショットを取る
  3. エクスポート実行したら直接 S3 バケットにコピー

もうこれ、案 3 の一択ですね!

案 1 はいちいちダンプファイルを EC2 インスタンスが中継しないといけないのでファイルサイズがでかいとその分時間もかかりますね。 S3 にダンプファイルを置かないのであればこの案もアリかなと思いますが、それだと案 2 と同じです(結局 EBS スナップショットは定期的に取るでしょうし

案 2 はネットワークコピーは RDS と EC2 インスタンス間だけですが、リストア時にスナップショットから EBS ボリュームに戻して EC2 インスタンスにアタッチしたり、実データを取ってくるために EBS ボリュームの初期化をしたりしてなんやかんや時間がかかります。 運用でのアクションが一番多いのもこのやり方です。 オペミスが怖いのであんまりやりたくありません。

対して、案 3 は中継となる EC2 インスタンスもいらないしリストアも S3 からすぐにダンプファイルを取ってこれるので、運用タスクも一番少なくてシンプルでいいですね! 時間も最短、かつ sqlplus でコマンド実行するだけで実現できるので運用負荷も少なくてすみそうです。

しかし良さそうと思って検証もせずに実装するとろくな目に合わないので、ちゃんと検証してみました。

 

実際にやってみたらちょっとだけハマった

設定の流れはクラスメソッドさんがブログで書いてくれていますので、↓を見てください(マジでいつもお世話になっております

dev.classmethod.jp

ちなみに必要な設定や運用で使うであろうコマンドたちは AWS ドキュメントに書かれています。

docs.aws.amazon.com

さあ設定もできたし、実際にエクスポートしたダンプファイルを S3 にアップロードしてみましょう。 こんなコマンドでアップロードします。

SQL> SELECT rdsadmin.rdsadmin_s3_tasks.upload_to_s3(
p_bucket_name => 'bucket_name',
p_prefix => '',
p_s3_prefix => 's3_prefix/',
p_directory_name => 'DATA_PUMP_DIR')
AS TASK_ID FROM DUAL;

結果を見てみましょう。

SQL> SELECT text FROM table(rdsadmin.rds_file_util.read_text_file('BDUMP','dbtask-xxxxxxxxxxxx-xx.log'));
 :
[ERROR] RDS doesn't have permission to write to Amazon S3 bucket name bucket_name and key s3_prefix/test.dmp.

あれ?おかしいな。 IAM ポリシーも RDS のオプショングループも AWS ドキュメント通りに設定したはずなのに、まだ権限が足らないと出ました。 もうちょっと詳しくエラー内容が出てればいいんですが、何度やってもこの文言しか出なかったので何が足りないのかこれだとわかりませんね。

ここで活躍するのが CloudTrail です。 当該時刻前後でフィルタしてみると、

User: arn:aws:sts::123456789012:assumed-role/Role_name/dbi-role-mem-id-xxxx is not authorized to perform: kms:GenerateDataKey on resource: arn:aws:kms:ap-northeast-1:123456789012:key/xxxxx

というアクセス拒否のエラーログが出てきました。 KMS 関連のエラーですね。

ふと思い出したのですが、対象の S3 バケットにはカスタマ管理 CMK を使った暗号化設定がしてあります。 なのでデータキーを取り出してそのデータキーを復号化しないといけません。 ↓のページが参考になりました。

aws.amazon.com

なので、RDS にアタッチする IAM ロールのポリシーは↓こんな感じで KMS 関連のアクションも許可しましょう。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:GetObject",
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::bucket_name",
                "arn:aws:s3:::bucket_name/*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "kms:GenerateDataKey",
                "kms:Decrypt"
            ],
            "Resource": "*"
        }
    ]
}

これで RDS for Oracle と S3 バケット間でダンプファイルの転送ができるようになりました。 あとはリストア時にこのダンプファイルをインポートしてやれば RDS for Oracle を DB インスタンス作成じゃなくて今ある DB インスタンスにデータをリストアすることができますね。

 

感想

実は RDS for Oracle から直接 S3 にダンプファイルを送れるとは知りませんでした。 お客様の何気ない一言からこの機能を知りました。 新機能が出たタイミングでは自分ごとではないにしても、いずれ少しでも関係しそうだと思った内容はちゃんと調べてみようと思いました。