自分探しの旅に出る
注：この記事はポエム記事です！読んでいただける場合は、斜め読みでお願いします。
転職をする、と決めた理由は沢山あります。
OSSのコントリビューターを目指したい、SIer以外の仕事がしたい…理由は沢山あります。
前向きなこと、後ろ向きなこと。もちろんそれらを自分で自分に問いかけ、そして言語化し、面接の際はそれを伝えました。その言葉に、何ら嘘はありません。
ではここで何を言いたいのか？と言うと…実は一番最初に転職をすることに決めた、その理由を書いておこうと思います。
それはあまりにも抽象的で、でもどこかに書いておかなければいずれ忘れてしまうものだと思うので、ここに書き残して置きます。
それは「ちっぽけな自分に気付いたから」なんです。
長年一つの技術、商圏を担当していた私は、気付けば複数人を取り纏めるようなポジションにいました。
自分の発言力は日に日に増し、私が「こうしたい」と言った内容は、気付けば組織や会社の決定となり、メーカーや開発ベンダを動かし…最終的には、顧客の判断基準にまで達しました。
すべてとはいかなくても、大枠は私の思うがまま。遠い未来のロードマップを作り、そこに達するまでの道筋を示せば、多くの人たちがそれに向かって進んでいく。
何の自慢話をしているんだ、と思う方もいらっしゃるでしょう。私も少し前までは、これは自分の今までの功績と実績が成したのだと、どこかでふんぞり返っていました。
そんな中、一つの本を読みました。その中に書いてあったある言葉に、頭が真っ白になりました。
「所属会社」という肩書きが無い貴方に、何ができるかを考えてみなさい。
「tomo」という個人に、一体何ができるのだろう？
今まで私が積み上げてきた実績は確かに自分の実績があるだろうけど、そこに所属会社や顧客会社のネームバリューに頼った事が、多々ある。
それに当たり前だけど、今まで築いてきた実績は上司やメンバーに支えてもらって出来たことばかりで、私は助けてもらっていただけだ。
10年以上同じ会社にいるからこそある、過去から積み上げてきた栄光に縋ってる。
勘違いをしていた。
私が出来ると思っていたことは、誰かの助けがある前提であって、私個人の力なんて本当にちっぽけだ。
そう思ったとき、何か、足下から崩れていくような気がしました。
それからはがむしゃらに勉強会に参加したり、社外の人とお話をしたり…私って何が出来るのか、何がしたいのか、どうありたいのかを考え始めました。
そうして沢山の人と出会って、自分に出来ることを、少しずつ模索していくようになりました。
DBをほんの少し知ってて
Ansibleとか自動化がちょっと知ってて
新しい技術に当たって砕けて玉砕すること
そんな自分をほんの少し知って、そしてありがたいことに内示をいただけました。
しかしこれだけしか出来ない自分に、本当情けないなと落ち込んでいたのも、正直ありました。
10年以上やってこれか、情けないなー。
そう思いながら、私は退職の挨拶をし始めることにしました。
役職者の方に挨拶にいくと、こう言われました。
退職受理されました⸜( ´ ꒳ ` )⸝
— tomo 𖠚ᐝ (@tomomo1015) February 28, 2020
お世話になった、相当上の役職者の方から頂いた言葉。
お前が散々悩んで行くって決めたんだろ？俺はお前の判断を尊重する。行ってこい。冒険してこい。ただ一つ約束しろ、楽しんでくることだ。辛くなったらいつでも言え。帰る場所はあるんだからな。楽しんでこい！
こんなに信頼してもらえていたなんて、知らなかったんです。
別の役職の方に挨拶にいきました。
「おまえに昔にやったあの調整とか、この調整とか…あんな風に、周りを巻き込んで動かす力。あれは…」
そんなこと自分が出来たの、知りませんでした。そういえば問題勃発するとざっくり切り分けして有識者に「HELP!!!」って言うのは、よくやってたかも。
チームメンバーに言いました。
エンジニア人生でTOP3に入る、光栄な言葉を頂いた…ちょっとだけ、自慢していいですか。
— tomo 𖠚ᐝ (@tomomo1015) February 4, 2020
「自動化に挑戦したり、世界初に無謀に挑戦したり。そんなあなたと一緒に仕事ができるから、楽しかった。あなたがいなくなるなら、僕がここにいる目的もなくなる。」
｡°(´∩ω∩`)°｡
それはみんなの助けがあってこそ、出来たんだよ。それに新しいことにチャレンジしなきゃ、私も楽しくないもの。皆が楽しいと思ってくれなきゃ、私も楽しくないよ。
開発ベンダさんに言いました。
「以前災害に遭った際、貴方が仕事より弊社のメンバーのことを最初に聞かれ、納期をすべて遅らせようと言ってくださったこと…」
そんな前のこと、覚えていてくださっていたの？納期遅らせるなんて、当たり前じゃないですか。開発ベンダさんを私は何より尊重する。その位の調整とスケジュール変更なんて、朝飯前ですよ。
言われたら当たり前のことなんですか。
自分が何が出来るのかなんて、周りが一番知ってたんです。
…若干過剰評価なので、そこは受け取った評価については、半分にして受け取らせて頂きましたが。
でもそれ以上に、こんなに優しい人たちと一緒に仕事をしていたんだと言うことを、改めて知りました。
うん、だから私が今まで積み上げた実績は周りに助けてもらって出来たことで…でも、それだけじゃなくて、ほんの少しは、自分の力もあった、と思っていいよね？
自分なんて、何も出来ないんだと思ってました。
でもどうも、何も出来ない訳じゃなさそうです。
でもまだもっと、出来ることがあるかもしれない。
出来ると思ったものが、もっと出来るようになるかもしれない。
だから、またね。
またどこかで、会おうね。
自分探しの旅に、行ってきます！！！
ワーキングマザーが転職するときに気をつけた5つのこと
こんにちは！tomoでございます⸜( •⌄• )⸝
月一で更新するって言ったのにどうなってるんだ という鋭いツッコミから目を逸らしつつ…今日はぜんぜん技術関係ない内容を記載します。
あの、唐突にですが。
私、転職することになりました⸜( ´ ꒳ ` )⸝♡︎
そこで、ワーキングマザーが転職活動や内定をいただけるまでに、あくまで私個人の意見ですが「やっておいた方がいいこと」を記載してみました。
もし私と同じように、子持ちのママさんが転職する際に、お役に立てれば幸いです。
あと、ママでなくてもパパでも、子持ちでない方にも、役に立つことがあるかも？しれないです。
ゆるーっと書きますので、どうぞお付き合いください⸜(๑’ᵕ’๑)⸝
- このブログを書いた人のステータス
- ①転職の目的を明確化しておく
- ②次の職場に、子育てに対する制度があるか
- ③次の職場のリーダーの子育てにどのくらい理解してくださっているか
- ④転職相談相手を作る
- ⑤子供がいることは、不利でもなんでもない
このブログを書いた人のステータス
①転職の目的を明確化しておく
転職って、なんとなーくマンネリ化してきたなーとか、明確な目的がない場合、結構ありません？
しかし、転職活動の面接では確実に、聞かれます。
これ、即答できて且つ相手を納得できるような説明ができないと、面接の時ちょっと気まずいことに。
なので是非、転職をしようと思ったときに、次のことを自分に自問自答してください。
「私は何故、転職をしようと思ったのか？次の会社に一体何を求めるのか？」
これが明確だと、面接で必ず聞かれる質問にさらっと答えられるので、選考も進みやすいです。
そこに子育てのことがあるのなら、是非それも素直に盛り込んじゃってください。
ちなみに私の場合…自分のやりたいことを探す旅に出て、半年かかりました。
ちょうど2019年の夏前から探し続け、秋ごろにやっと腹落ちした。そんな感じです。
②次の職場に、子育てに対する制度があるか
まず、子育て中のパパママに優しい制度があるかどうか、をその会社のHP等で確認します。
産休育休は当たり前にあるとして、保育所が会社の中にあったり、ベビーシッター制度があったりと、最近の企業は色々な制度を取り入れられているので、是非チェックしてください。
私が最終的に大事にしたのは「リモートワーク」でした。
保育園の登園やお迎えの時間など、子持ちは子供中心に時間が決まります。これは本人の努力ではどうにも出来ないのが、現実ですよね。
こうなると、会社の通勤時間を短縮する、又は子供を寝かしつけた後に仕事をするリモートワークは、すごく大切。ごめんなさい、ないと無理。
（このブログ書く前も、プロジェクトの進捗報告をリモートワークで書いてた）
③次の職場のリーダーの子育てにどのくらい理解してくださっているか
実はこれが一番、大事かもしれない。
②で制度などを記載しましたが、実は会社の制度って、結構どうにかなったりするものなんです。
それよりも大事なのは
「会社のリーダーや決定権を持つ方が、自分の境遇を理解して共感してくれる人か？」
ということ。
制度があっても、「制度はあるけど…とはいえ仕事は仕事だからさ、困るよ〜」とか言う人、居るんです！マジで！！( ; ›ω‹ )
面接の時って、必ず部長やCTOクラスと面接をしますよね。そこで、自分が子持ちであることなどを話た時、どれくらい共感してくださるか、観察してみてください。
私が次の会社を決めた決め手は、実はここが大きいです。
そしてこの点は、私自身の経験からも非常に重要なウェイトを占めていました。
実際、自分のチームメンバーには会社の制度を無視して、家庭の事情を優先してリモートワーク許可したり、体調と通院優先で時短勤務にしたりと、家族やご自身の事情を最優先にしてもらっています。
実はこれ、子育てだけじゃなくて。介護もです。または、ご自身が何か持病をお持ちだったりした際も、同じように聞いてみてください。これ本当大事。
④転職相談相手を作る
ワーママっていう生き物はですね…家事育児仕事だけで、もう毎日ヘトヘトになるんですよ( ; ›ω‹ )
なので転職をしようにも、何から着手したらいいのかわからないし、分かっても毎日のルーティンだけで、もういっぱいいっぱい。
だから時々、相談できる相手が欲しい。なので是非、相談相手を作ってください。
私の場合、Twitterやmeetupでお知り合いになった（一方的にそう思っている）お友達の方々に、沢山相談に乗ってもらいました。
なんと、紹介までして頂いたり…そして気づけば、転職エージェント無しで、転職先が決まるという…
本当に私、友人や周りの人が優しい人ばかりで…この点だけが、自分の人生の誇りです。
⑤子供がいることは、不利でもなんでもない
これが、最後に言いたいことです。
子供がいることって、不利だと思っていました。
残業ができない。子供の事情で会社に行けないことがある。
これは残念ながら事実で、目を逸せない現実で…でもそれは、この世に存在する多くの人が、これを強いてきた。
この世の人間は全て、父親と母親から生まれてきたのです。
誰しもが、親にお尻を拭いてもらって、泣いているをあやしてもらって、熱が出たときに抱きしめてもらって…そうして、育って大人になったんです。
子持ちの親を蔑ろにすることは、自分自身の親を蔑ろにすることと、実は変わらないんですよね。
私は自分が子どもを産んで育てて改めて、世の中の「親」という人たちを、尊敬しています。
だからその尊敬してくれる人が、働きやすい場所を作りたい。そんな場所にいたい。
子供がいることを不利だと捉える場所なんて、こちらから願い下げちゃいましょ⸜( ´ ꒳ ` )⸝
大丈夫。私だって、転職できた。
子供がいても、「おいで」って言ってくれる場所は、沢山ありますよ！
さてさて、記載したいことは以上です。
少しでも、誰かのお役に立てれば幸いです⸜( ´ ꒳ ` )⸝
2019年の振り返り
2019年、気づけば今日で終わり！
ということで、簡単に今年一年間を振り返ってみようと思います(꜆꜄•ω•)꜆꜄꜆
2019年頑張ったこと
自分が何をしたいのか、旅に出てみつけられたこと
これは私の人生の中で、就活以来の「自分探しの旅」でした。
今や MySQLだ、Asnibleだ、k8sだ言っていますが、2019年の当初は「データサイエンス」の方に進もうと考えていたりしました。
何せDBにデータ入れるのが好きだったし、そのデータ使ってあれこれ考えるのも楽しそう！なんて思っていたのです。いえ、本当に。（昔Hadoop系結構やっていたりもしていたので）
実際、データサイエンスエンジニアの養成をやっている会社さんに、研修内容の説明会に行ったりもしました。
でも、なーんか違ったんです。しっくりこない。
で、そんな中、別に記載しますが、Ansibleへの挑戦やMySQLでどハマりして、技術meetupに出るようになり、自分のやりたいことが見えてきました。
実は数年間、ずっとモヤモヤしていたことだったので、これは何よりも嬉しいことでした⸜( •⌄• )⸝
登壇に初挑戦、アウトプットを少しずつ出す
「イベントで登壇しませんか？」と某企業様から言われた時は、実は障害対応中で何言われてるのか、言葉が理解できませんでしたw
正直、死ぬほど悩みました。でも、もうこんな機会、二度とないって思った。背中を押してくれた人がいた。
だから、思い切って出ることにしました。恐怖もあるけれど、それより何もしないほうが絶対後悔する。その方が嫌だ。
結果、沢山のご意見をいただきました。本当にびっくりしたし、何よりも嬉しかった。
私の話を、聞いてくれるだけじゃなくて、共感していただいたり、学びになったよ！と言ってくださったことが。
自分の体験をアウトプットすれば、同じ学びを共感していただけたり、同じミスを事前に回避していただけたりするんだ…！ということは、大きな学びになりました。
調子乗って、Ansible NW部にも登壇してみましたw ↓
But、Advent Calenderに遅刻しまくったのはイカンよ私！！
憧れの先輩に、少し、追いついた
これだけ、仕事の話。少し前提が長いですが、お付き合いください。
うちの会社には新人にトレーナーがつきます。私のトレーナーはとにかくめちゃくちゃ優秀な方で、社内でも非常に評価の高い方でした。
そんな先輩は私が5年目の時に直属上司になりました。その頃、先輩は毎週のように客先に足を運び、顧客と様々な事を話しながらシステム改善や数年後に計画されている案件内容をヒアリングするなど、エンジニアとしてだけでなく営業顔負けのことをさらっとこなしていました。実際それで、いくつかのRFI/RFPを随意契約に近い運びに持ってきていました。これはSIerとしては最も評価される進め方だと思います。
（後から本人から「それはお客様から話をしようと言われただけで、私は何もしていないのよ。」と言われたのですが、話しやすい人、時間をとって話をする価値がある人と認められていたからです）
そんな先輩は、その翌年に他社に転職されました。
その後、様々な課長の元で働きましたが、先輩の域にまで達した方はいませんでした。
RFI/RFPは出てくるまで把握せず、むしろ先輩が獲得した商圏を他社に奪われるまでになり、私自身、非常に悔しかったです。どうしたらいいんだろうと悶々としていた今年。ヤケを起こした私は、先輩と同じ事をしてみることにしました。
頭は良くないし、私なんか〜とグルグル悩みましたが、そうは言っても何も進まない。取り敢えずアタック！！と、個別に雑談アポを取ることにし…結果、「RFI/RFPが出る前にその内容を事前に把握し、実装方式を相談されるまでに至った」ことは、私の中で取り敢えず100点ってことにしました(ˉ ˘ ˉ; )
今では毎週客先に行って、あーでもないこーでもないと議論する日々です。
ほんの少し、先輩に追い付いたかなぁ⸜( ´ ꒳ ` )⸝
MySQL InnoDB Cluster 反省会
この記事は「MySQL Advent Calendar 2019 21日目」です。
これまた大遅刻となってしまって申し訳ございませんでした;(´◦ω◦｀):
これも言い訳はダメだぞ自分！
さて、今年中にどうしても書き残して置きたかった内容があったのですが、ありがたくも「Adovent Calenderに書いていいよ！」というお話しをいただいたので…書かせていただきます。
題して「MySQL InnoDB Cluster 反省会」。
何もMySQLを知らない人間が、いきなり MySQL InnoDB Cluster Group Replication を導入した、そんなお話です。
前提
InnoDB Clusterを採用した理由
採用する前にやったこと
- PoCはもちろんやりました。ただしアプリケーションは仮のものだったので簡単なオンライン処理だけしか出来ず、少し流して問題ない事を確認しました。バッチも数万件流してそれで終わり。そしてここが、当たり前ですが一番命取りになりました。
- InnoDB Clusterの構成、そしてそれが該当システムにどれだけ適しているかを顧客に説明し、OKを頂きました。（お堅いですが、しかしチャレンジには賛成してくれる、非常にありがたいお客様でした）
反省会（マネジメントチックな話）
MySQLはコミュニティのものである
分かってはいたんです。MySQLはOSSである事を。ただライセンスを買っているんだから、Bug出たら個別パッチをOracleDB並に出してくれるんだろうと思い込んでいました。
けれどMySQLは、基本はコミュニティのものです。ライセンスがあったとしても、Oracle社がコミュニティを無視して個別パッチどんどん出す訳がないのです。（本当にやばいのは出してくれます）
だからなぜ、パッチを出してくれないのか、最初はわからなかった。SIerあるあるなのかもしれないですが、狭い世界で生きてきた私には、当時本当に分からなかったんです。
この考えを自分が改めるようになったのは、次の出来事があったからでした。
複数バージョン間レプリケーションがサポートポリシー変更
プロジェクト期間は1年以上あり、実際提案活動を開始した際から考えると、検討を開始したのは実質、1年半前でした。
その当時、「マスターよりメジャーバージョン 2 つ以上新しいスレーブとの間で複製できる」というサポートポリシーでした。その為、移行方式は、 5.X → 5.X → 8.0.X に多段レプリケーションで移行する事を、提案＆受注時に決めていました。
プロジェクトが進み、いざ移行検証を開始します。すると想定していないエラーが出たので、サポートに問い合わせをしました。そうすると「2つ以上のバージョン間のレプリケーションはサポートしていませんよ」という回答が来ました。
そしてそこで初めて、サポートポリシーが変わっている事を知ったのです。
@hmatsu47 さんの「MySQL レプリケーションのサポートポリシーがこっそり (?) 変わっていた話」をみて、我々は改めて、サポートポリシーの変更を知りました。
この時また、私はいつものノリでOracleさんに「どうゆうことか」と問いただします。
清く正しく、先輩の真似をしました。そしてそれは、プリプラの製品に対しての対応であれば、正しかったのかも、しれません。
でもその中で、自分のこの行動がそもそも正しいのか？と、疑問になり始めたのです。
これが、私のその後を変えるきっかけになりました。
これ以降、積極的にOSSコミュニティのmeetUPや勉強会に参加するようになりました。思えば、当然のことなのです。
受け身ではなく、前のめりぐらいの勢いで自分から学び、情報収集することは、当たり前である事を。
反省会（技術的な話）
InnoDB Cluster用にメモリ領域を用意
InnoDB Clusterの管理情報などなどのため、採用される際は現行のメモリサイジングから最低1GB以上は多くメモリ領域を確保する必要があるそうです。
個人的な反省として、+5GBサイジングしておけばよかったな、と反省…
レプリケーションの性能問題
NWの問題もあったかもしれないのですが、MasterからSlaveにレプリケーションするデータ伝搬がとにかく遅い問題が発生しました。
これはPoCの際に「簡単な処理を少々流しただけ」で済ませていたことが原因でした。
当たり前と言われればそうですが、バッチ処理を流したところ、MasterとSlave間で数時間分のデータ差分が発生しました。
そのうち、Masterに溜まった「伝搬待ちデータ」がメモリを食い尽くし、Masterが新規メモリ領域を確保できず、Coreを吐いてDownするまでに至りました。
これを解決する為に、Multi Threads Slave（以下MTS）を1から複数に変更しました。
これはレプリケーションの遅延を回避するチューニングとしては正しい対応でしたが、ここで別の問題が発生します。MTSが複数になったが故に、Slave側でデッドロックが発生し、場合によってはSlaveがGroup replicationから追放されてしまう状況になりました。
MTSを複数にしなければ Master がDown、MTSを複数にするとSlave でデッドロック。
勿論、後者を選択しました。MasterのDownを絶対に避ければいけないことは、説明の必要もないと思います。
でもこの決定は、決して容易ではなかったです。何せそれで苦労するのは、顧客や運用担当なのです。彼らの仕事に足を引っ張ることになる…問題があるものを運用する事を、強いるわけですから。
反省会（まとめ）
- InnoDB Clusterを採用する際は、PoCでオンライン処理もバッチ処理も商用最大クエリを一度は流して、レプリケーションの様子をみる。アプリからの処理が全く同じでなくていいので、例えばバッチを100万件流すのなら、何でもいいからとりあえずそれだけの負荷はDBにかけてみる
- MTSは出来れば複数化しないほうがいいと思う。でも性能の為ならデッドロックを許容するか、等、何を優先して何を犠牲にするのか、考えなくてはならない場面に遭遇するかも
- メモリは多めにとったほうがいい。少なくともInnoDB Cluster用に1GB以上は追加で確保してください
- 最新機能だからOracleさんのサポート入れておく事を提案した私、グッジョブ。ご支援がなかったら、私のレベルだったら確実に詰んでた
終わりに
でもね、でもね…これが言いたい。
MySQL InnoDB Cluster すごくいい⸜( ´ ꒳ ` )⸝
- システムの可用性は上がった
- DBサーバ1台あたりの負荷分散ができた
- MySQL Routerが自動で接続先変えたりしてくれるのでMasterが何らかでDownしたら、Slaveが自動で Master になってくれる
- 何より、これOSSとして製品デフォルト機能！！
勿論苦労はしましたが、私はこのInnoDB Clusterに携わって、本当に楽しかったです。
そして、meetUPに参加して多くの方に出会えた事、新しい世界を知った事。OSSに対する感謝を学びました。
最新のMySQLでは clone 機能でInnoDB Clusterもより作りやすくなっているとか。くぅ〜これは是非たくさん遊ばないと！ですね。
そして一番最後に。
こんな私と、それを支えてくれたDBAのメンバー、フォローしてくださったPMOの先輩、我がままに付き合ってくれた開発メンバー、OSリソースの解析を手伝ってくれたインフラエンジニア、サポートのフォローをしてくださったOracleさん、問題を真摯に受け止めて理解し許容していただたお客様。
meetup等で多くのフォローをしてくださった、大勢のみなさま。
そして何より、こんな素晴らしいMySQLを作ってくれた多くの見知らぬ方々に、最大の感謝を！！
また来年、MySQLのAdvent Calender が書けますように…！
（そして遅刻しませんように ←これな）
DBへの作業自動化で気をつけていること
この記事は「Ansible Advent Calendar 2019 18日目」です
まず…まずですよ…
遅くなって大変申し訳ございませんでしたﾟﾟ\(´O`/)°゜ﾟ
言い訳は、しない…
さて！改めまして、tomoと申します。DBAをやりながらAnsible芸人もやってます( ´ ▽ ` )
今日はAnsibleをDBに対して使用する際、私が気をつけていることを書いてみます。
ポエマー記事です。全て個人見解ですので、あらかじめご了承ください。(色々お許しください）
何故DBオペレーションを自動化したいの？
技術的な話をする前に、DBに対する自動化に対する想いについて、少し語らせてください。
DBAの人数が少ない
DBAの数ってNWとかサーバエンジニアより絶対数が少ないと感じています。
複数のシステムを1人のDBAが担当しているとか、あるある事案。
そうすると、DBAとしては「いかに問題を発生させないようにするか」を考えます。
例えば、AシステムのDBの障害対応していたら、今度はBシステムのDBも障害が発生した。なんてあるあるですよね。これが、DBAが最も避けるべき未来だと思います。
そのために一番大切なことは「日頃からDBをモニタリングし、少しの変化も見逃さないようにする」ことではないかな、と。そしてそのタスクの中で「情報収集」に対していかに正確に、いかに早く行うべきかが焦点となるんじゃないかな、と思っています。
だから私は、DBオペレーションこそ自動化をすべきと考えています。
（まぁ監視＆モニタリング頑張ればいいんだよねって論は大正解ですがw）
DBはこれから進化をするもの
10年以上前だと、DBはシステムに一つか二つしかない、アプリサーバ等の他に比べたら圧倒的に数が少ないエンティティだったように思います。複数台に同時にログインして操作することなんて滅多にないし、そもそも許されていないシステムも多くあったんじゃ無いかなぁ、なんて。
ただし最近ではマイクロサービスだったり、CloudNativeなんて時代に。DBは更に多様化、複雑化、複数化していくんじゃないかな、と思っています。
インスタンスの数が三桁とか、案外珍しく無い時代になっているような…?!
最初は勉強のために手で一つずつコマンド打ったオペレーションをした方が良い。でもいつか、それでは追いつかなくなる。事業やサービスの加速に、DBがボトルネックにならないようにする１つの手段として、「DBの自動化」があるのではないかな。と思っています。
この記事では、RDBに対する自動化を前提で書きますが、根本的なところは「DB」であれば基本は変わらないんじゃないか、と思っています。
DBへのAnsibleによるオペレーション自動化において気をつけていること
100点じゃ無いことを理解する
冪等性など、出来ないことをあれこれ悩んでも仕方ありません。勿論、モジュールが対応していれば冪等性を担保できるので、それはそのまま、ありがたく使えばいいかなと思います。
ただ、DBは操作言語が大抵SQLなので、実行したSQLの冪等性を担保するのはAnsibleだけではできないです。DDL文とか無理やん。なので、最初から諦める。
冪等性を約束するのは、AnsibleではなくてDB自体がしたらいいんじゃないでしょうか。
もしどうしても戻したいのであれば、バックアップ＆リストアをすればいい。DBは基本的にその辺りは高機能だから、DBに頑張って貰えばいいと思っています。
Playbookだけでなく「実行するSQL」も気をつけて
恐らく大抵が、SQLファイルを copy でDBサーバに持っていって、それを実行するという方式だと思います。となると怖いのが Ansible の Playbook だけでなく実行するSQLファイル。
間違っても TRUNCATE とか入ってたら泣くので、実行するSQLファイルはしっかり確認してます。
慣れるまでは「select」系の処理だけにする
今私がAnsibleで自動化しているのは、ほとんどDBに対して操作を行わない select 系です。それも V$INSTANCE(Oracle) とか performance_schema(MySQL) を覗く系です。
現在ではそのほかの処理も実務で実行しています。表領域の拡張、パラメータ変更、バックアップリストア…でもそれも、まずはSQLファイル単体でしっかり動作確認した上で実施します。
実行前に必ず「実行しますか？」をきく。
よく使っているのは、こんなplaybookです。（サンプルです）
## ./vars/common.yml YES_CONFIRM_STR: [ "Y" , "YES" ] INPUTABLE_LIST: [ "Y" , "YES" , "N" , "NO" ] INPUT_RETRIES: 3 INPUT_RETRY_DELAY: 1
## ./tasks/yes_no.yml - name: 確認メッセージ pause: prompt="{{ disp_msg }} (y/n)" register: user_yes_no until: user_yes_no.user_input|upper in INPUTABLE_LIST retries: "{{ INPUT_RETRIES }}" delay: "{{ INPUT_RETRY_DELAY }}" ignore_errors: yes - name: 入力結果による処理中止 fail: msg=“！！ユーザーの入力により処理を中止します！！" when: user_yes_no.user_input|upper not in YES_CONFIRM_STR run_once: true
## main.yml - name: DBリストアPlaybook hosts: "{{ host_name }}" gather_facts: false become: yes vars_files: - vars/common.yml tasks: - name: DBリストア実施前確認 import_tasks: ./tasks/yes_no.yml vars: disp_msg: "ホスト名 {{ host_name }} へDBリストアを開始して良いですか？"
この yes_no.yml を main.yml のなかにincludeしています。
これをすれば、うっかりbash等の過去履歴から誤って Playbook を実行してしまっても、一瞬「ん？？？」と踏みとどまることができます。
自動化したいのにyes/no聞くんかいっ！というご意見は最も。全然スマートじゃない自覚はあります。
でも間違ってDBリストアするより、マシだと思うんですよ。
ansibleである必要って？
まっったく無いです。
これについては色々議論があると思うのですが、自分が慣れているものであればなんでもいいんじゃ無いでしょうか。
sh py go .....開発言語は沢山ありますし、他にもオーケストレーターのツールはあります。慣れてるものを使えばいいと思います。
ただ私は個人的に、以下の理由でAnsibleが気に入っているので使っています。
さいごに
来年一年間は、DBの自動化を頑張って行きたいな！と思っております。
と言っても、DBAとしても自動化エンジニアとしても未熟ですが、がばるぞーー！！
Flex DiskGroup 使ってみたよ！
この記事は JPOUG Advent Calendar 2019 16日目の記事です(꜆꜄•ω•)꜆꜄꜆
さてさて、昨日の記事は multilayerさんの「僕がAWRレポートを好きな理由（DBメモリ編）」でしたね。
非常に勉強になりました。私もAWRには日頃お世話になっていますが、いつもDB待機イベントばかりみていて、メモリのところはアプリの性能に問題ない＆メモリ使用率が上がっていなければスルーしていました。
ちょうど明日、仕事で見ないといけないので参考にさせていただこうと思います。
JPOUG アドカレ2回目になります。前回で結構エネルギー消費してしまったので、すいませんだいぶ薄い内容になりますがご容赦ください。
本日のお題は「Flex DiskGroup 使ってみたよ」です( ᐢ˙꒳˙ᐢ )
すいません！「Flex ASM」ではなく「Flex Diskgroup」です
Flex DiskGroupとは？
- Oracle GridInfrastracture 12.2から追加された新機能
- 従来存在したDIsk Groupの属性 Nomal/High/External に加えて「Flex」が登場！
- Flex DiskGroupの中にQuota/File Group を作成し、File Group 毎に「Nomal/High」を設定可能
- CDB/PDB環境前提、非CDB/PDB環境、どちらでも使えます
- 詳しくは管理者ガイドへGO！
概要図は以下のような感じです↓
Flex DiskGroup 作る
使用に関し、以下前提条件にご注意ください。
- 上記リンク先のマニュアルをよく読んでおいてください。（そりゃそうだ）
- Oracle Grid Infrastructure 12.2 以上の環境でないと使用できません。
- ASMのディスクグループ属性 COMPATIBLE.ASM と COMPATIBLE.RDBMS が12.2以上に設定されている必要があります。12.2以上でインストールしても、この設定値はデフォルト11.2とかになってることがありましたので、ご確認下さい。
- Nomal/High → Flexに属性変換は出来ますが、Flex→Nomal/Highは出来ません。一方通行なのでご注意ください
ちなみに、asmcmdで作る場合は、ざっくりこんな感じです。環境は19cです。
Quota Groupの作り方
[grid@testdb ~]$ asmcmd ASMCMD> lsqg -G FLEX1 Quotagroup_Num Quotagroup_Name Incarnation Used_Quota_MB Quota_Limit_MB 1 GENERIC 1 140824 0 ASMCMD> mkqg -G FLEX1 TESTDB Diskgroup altered. ASMCMD> lsqg -G FLEX1 [Fri Sep 27 15:48:29.164 2019] Quotagroup_Num Quotagroup_Name Incarnation Used_Quota_MB Quota_Limit_MB 1 GENERIC 1 140824 0 2 TESTDB 1 0 0
File Groupの作り方
ASMCMD> lsfg -G FLEX1 File Group Disk Group Quota Group Used Quota MB Client Name Client Type DEFAULT_FILEGROUP FLEX1 GENERIC 0 TESTDB FLEX1 GENERIC 140824 TESTDB DATABASE ASMCMD> mvfg -G FLEX1 --filegroup TESTDB Diskgroup altered. ASMCMD> lsfg -G FLEX1 File Group Disk Group Quota Group Used Quota MB Client Name Client Type DEFAULT_FILEGROUP FLEX1 GENERIC 0 TESTDB FLEX1 TESTDB 140824 TESTDB DATABASE ASMCMD> chfg '<filegroup name="TESTDB" dg="FLEX1"> <p name="redundancy" value="high"/> </filegroup>'
ご確認。
ASMCMD> lsfg -G FLEX1 --filegroup TESTDB File Group Disk Group Property Value File Type TESTDB FLEX1 PRIORITY MEDIUM TESTDB FLEX1 COMPATIBLE.CLIENT 19.0.0.0.0 TESTDB FLEX1 REDUNDANCY HIGH CONTROLFILE TESTDB FLEX1 STRIPING FINE CONTROLFILE TESTDB FLEX1 REDUNDANCY HIGH DATAFILE TESTDB FLEX1 STRIPING COARSE DATAFILE TESTDB FLEX1 REDUNDANCY HIGH ONLINELOG TESTDB FLEX1 STRIPING COARSE ONLINELOG TESTDB FLEX1 REDUNDANCY HIGH ARCHIVELOG TESTDB FLEX1 STRIPING COARSE ARCHIVELOG TESTDB FLEX1 REDUNDANCY HIGH TEMPFILE TESTDB FLEX1 STRIPING COARSE TEMPFILE TESTDB FLEX1 REDUNDANCY HIGH BACKUPSET TESTDB FLEX1 STRIPING COARSE BACKUPSET TESTDB FLEX1 REDUNDANCY HIGH PARAMETERFILE TESTDB FLEX1 STRIPING COARSE PARAMETERFILE TESTDB FLEX1 REDUNDANCY HIGH DATAGUARDCONFIG TESTDB FLEX1 STRIPING COARSE DATAGUARDCONFIG TESTDB FLEX1 REDUNDANCY HIGH CHANGETRACKING TESTDB FLEX1 STRIPING COARSE CHANGETRACKING TESTDB FLEX1 REDUNDANCY HIGH FLASHBACK TESTDB FLEX1 STRIPING COARSE FLASHBACK TESTDB FLEX1 REDUNDANCY HIGH DUMPSET
メリデメ
メリット
デメリット
- DB単位でしか設定できない。（データファイル毎に設定できたりしたらもう少し利便性が上がるのでは？）
- Flex上でHighにしても Redundancy は 1。つまり、DISK障害に対する挙動はNomalと変わらない。
障害グループが5つ以上の場合、許容されるディスク障害は2つです。障害グループが3つまたは4つの場合、許容されるディスク障害は1つです。
docs.oracle.com
デメリットの最後が、猛烈に痛かったです…Flexの中のFileGroup をHighにしても、Storageの障害グループ3つに対しディスク障害1しか対応できません。
例えば、ExadataのEighth/Quarterで Flex Diskgroup にデータ領域を持つと、Storage Server の1台障害は耐えられますが、2台障害が発生すると、DBは停止することになります。
（実は最初、この特性を見逃していて 障害試験で Redundancy を 1 状態にしたら、もれなくDBがお亡くなりに…）
二重障害と言えばそうですが、仮に1台がHW障害などで停止していた場合、もう1台が何かあると、DBダウン＝サービス停止、となる場合はかなりのリスクになります。
こうゆう場合は、Flex Diskgroupを採用するメリットは無いので、お勧めできないなと思います。
個人的な感想
今後発展予定の機能なのかなーと思いました。
PDBが大量にあるシステムならいいかなと思いつつも、 Redundancyのところが辛かったです。
今後のUpdateが楽しみ、ということで⸜( •⌄• )⸝
明日は kjmtgmさん のアドカレ！( ˙꒳˙ᐢ )
TimesTenって知ってる？
この記事は JPOUG Advent Calendar 2019 6日目の記事です。
改めて初めまして！Twitterではいつもお世話になっております⸜( ´ ꒳ ` )⸝
初ブログが Advent Calendar って大丈夫かな、とビクついてます。（他の方々が強すぎて怖い）
と怖がっていても仕方ないので、自分にできること、発信できることを記載したいなと思っています。
これからどうぞ、宜しくお願いします！
さて、今日はTimesTenという製品をちょっと紹介させてください。
長くなりそうなので、最初に結論を書きます。
Command> select count(*) from ORACLE.TEST_TABLE; < 1655342 > 1 row found. Execution time (SQLExecute + Fetch Loop) = 0.041723 seconds.
みてみて！めっちゃ早い！！！
（インメモリDBだから早いの当たり前とかいうの禁止/というか件数検索かい）
▼目次
TimesTenとは
TimesTenはTimesTen社が開発したインメモリDBです。
2005年にOracle社に買収された製品で、現在でも開発/販売されている製品です。
ラインナップ的にはOracleDBと同じ枠のよう（営業さんとか）、開発されてる場所もUS本社のDB棟です。
ざっくりいうと、機能が二つに分かれています。
- TimesTen Classic
- TimesTen ScaleOut (ちょっと前はVelocity Scaleって呼び名だった)
今回は前者の「TimesTen Classic」について記載します。というか、多分世界的にもこの使い方している人がほとんどなのではないかなと、個人的には思っています。
このClassicですが、昔は「Cache Connect」とか呼んでいた気がします。その名の通り、「参照先のOracleDBのデータを読み込んでメモリ上に展開する」機能が非常に優秀です。
製品のアーキテクト概要を以下に記載します。（いつもの雑絵ですいません）
DBに更新された情報がどうやってTimesTenまでデータが伝搬されるのか、流れをざっくり記載します。
どんな場面で使うのか
一般論ですが、以下の場合はお勧めしています。
- OLTP型のDBで、特にR>Wの傾向がある
- Read性能に悩んでいる
- 元々OracleDBを使っていて性能を上げるためにインメモリDBを使いたいが、KV型ではなくそのままSQLを使い続けたい
- OSSではなく、メーカーサポートして欲しい
逆に、こんな場合はお勧めしていません。
- DWH型、W>Rの傾向
- DBのカラム変更やテーブル増減の頻度が激しい
ライセンス費かかるのなんて無理
メリデメ（個人の意見）
メリット
- 早い。めちゃくちゃ早い。μsecで応答してくれるの凄い
- 学習コストがやや低い。OracleDBと大体同じ操作（alter文とか）ができるし、PL/SQLも打てるので、特にOarcleDB知ってる人はすぐ覚える
- DB更新データを自動で取ってきてくれるのが大変楽。作り込み不要
デメリット
- OracleDB側のTable構成変えると、毎回全件データ読み込みし直しが運用的に辛い
- 誰かがセッション繋いでいる状態だと、停止できない。アプリ側を毎度停止or片寄する運用が手間
これOSSにしてくれたらもっと流行ると思うんだけどなー？
結論、性能については◎なのですが、運用がちょっと△です。
使ってみる
こんなテーブルをOracleDBに作ってみました。
CREATE TABLE tomo ( user_id VARCHAR2(128), user_name VARCHAR2(128), attribute VARCHAR2(512), CONSTRAINT pk1 PRIMARY KEY(user_id) ) TABLESPACE table_space;
ではこのテーブルのキャッシュを、TimesTenに作成します。
Command> create readonly cache group TTADM.TOMO_CACHE > autorefresh > mode incremental > interval 6000 milliseconds > /* state on */ > from > ORACLE.TOMO ( > USER_ID VARCHAR2(128 BYTE) NOT INLINE , > USER_NAME VARCHAR2(128 BYTE) NOT INLINE , > ATTRIBUTE VARCHAR2(512 BYTE) NOT INLINE, > primary key (USER_ID)) > unique hash on (USER_ID) pages = 4000;
細かい内容は割愛しますが、これでTimesTen側にキャッシュが作成されました。
これを、キャッシュグループと言います。キャッシュグループのステータスを確認してみましょう。
Command> cachegroups TTADM.TOMO_CACHE; Cache Group TTADM.TOMO_CACHE: Cache Group Type: Read Only Autorefresh: Yes Autorefresh Mode: Incremental Autorefresh State: On Autorefresh Interval: 6 Seconds #6秒間隔でOracleDB側に問い合わせ Autorefresh Status: ok Aging: No aging defined Root Table: ORACLE.TOMO Table Type: Read Only 1 cache group found.
不思議な感じですが、これでTABLEもできてます。（ReadOnlyですが）
Command> desc tomo; Table ORACLE.TOMO: Columns: *USER_ID VARCHAR2 (128) NOT INLINE NOT NULL USER_NAME VARCHAR2 (128) NOT INLINE ATTRIBUTE VARCHAR2 (512) NOT INLINE 1 table found. (primary key columns are indicated with *)
この時点では、OracleDB側もTimesTen側も、データ件数は0です。
Command> select * from ORACLE.tomo; 0 rows found.
さて、ではここにデータを投入すると、どうなるでしょ？
OracleDB側にこんなデータを投入します。
INSERT ALL INTO tomo VALUES ('k8s_1', 'koba-san', 'SumikoGurashi') INTO tomo VALUES ('k8s_2', 'yoshi-san', 'CoreDQwalker') INTO tomo VALUES ('k8s_3', 'vargo-san', 'NomalDQwalk') INTO tomo VALUES ('k8s_4', 'cotco-san', 'Boss') INTO tomo VALUES ('k8s_5', 'inductor-san', 'TSUYOI') SELECT * FROM DUAL;
最近会った人シリーズ。言いたいことがある方は Twitterでお願いします。 ←
すると TimesTen側に…！
Command> select * from ORACLE.tomo; < k8s_1, koba-san, SumikoGurashi > < k8s_2, yoshi-san, CoreDQwalker > < k8s_3, vargo-san, NomalDQwalk > < k8s_4, cotco-san, Boss > < k8s_5, inductor-san, TSUYOI> 5 rows found.
データが入ってきますᐠ( ᐢ ᵕ ᐢ )ᐟ
じゃんじゃんOracleDBにデータ投入しますよ〜
INSERT ALL INTO tomo VALUES ('MySQL_1', 'awache-san', 'Senior') INTO tomo VALUES ('MySQL_2', 'yoshi-san', 'God') INTO tomo VALUES ('MySQL_3', 'yamasaki-san', 'God2') INTO tomo VALUES ('MySQL_4', 'sakai-san', 'GIS') INTO tomo VALUES ('ansible_1', 'yokochi-san', 'TEKUNABE') INTO tomo VALUES ('ansible_2', 'mofumofu-san', 'NANACHI') INTO tomo VALUES ('ansible_3', 'tetematsu-san', 'TENKO') INTO tomo VALUES ('ansible_4', 'zaki-san', 'OpenShiftMaster') INTO tomo VALUES ('ansible_5', 'yascaim-san', 'NWmaster') INTO tomo VALUES ('ansible_6', 'ippandansei-san', 'Climbing') INTO tomo VALUES ('ansible_7', 'nakamura-san', 'ansible-BOSS') SELECT * FROM DUAL;
値は特に気にしないでください。
TimesTen側を見ると…
Command> select * from ORACLE.tomo; < k8s_1, koba-san, SumikoGurashi > < k8s_2, yoshi-san, CoreDQwalker > < k8s_3, vargo-san, NomalDQwalk > < k8s_4, cotco-san, Boss > < k8s_5, inductor-san, TSUYOI > < MySQL_1, awache-san, Senior > < MySQL_2, yoshi-san, God > < MySQL_3, yamasaki-san, God2 > < MySQL_4, sakai-san, GIS > < ansible_1, yokochi-san, TEKUNABE > < ansible_2, mofumofu-san, NANACHI > < ansible_3, tetematsu-san, TENKO > < ansible_4, zaki-san, OpenShiftMaster > < ansible_5, yascaim-san, NWmaster > < ansible_6, ippandansei-san, Climbing > < ansible_7, nakamura-san, ansible-BOSS > 16 rows found. Execution time (SQLExecute + Fetch Loop) = 0.000616 seconds. Command>
TimesTenには一切データ投入していませんが、ちゃんとみれるのがお分かりいただけますでしょうか。
性能結果
あまり良い例を作れなかったのですが…例えば、OracleDBで4秒かかるcountSQLがあります。
ORACLE@oracledb1> select count(*) from TEST_TABLE; COUNT(*) ---------- 1655342 経過: 00:00:04.95
これを、TimesTenで実行すると…？
Command> select count(*) from ORACLE.TEST_TABLE; < 1655342 > 1 row found. Execution time (SQLExecute + Fetch Loop) = 0.041723 seconds.
0.04秒だよ⸜( ´ ꒳ ` )⸝ 早いね！
あとがき
- 早い！と思って頂けたら私としてはモウマンタイです。
- 実は環境構築をMac Dockerでやっていたのですが、OracleDBのコンテナでつまづいたので間に合いませんでした…そもそも前提として、dockerに対する勉強/経験値が足りなかったのですが、今回色々勉強になったなと（特にNW Seg同じにするの忘れてて大変痛い目にあった）思いました。これもいい経験。環境構築記事は半分できてるので、いつかUPしたいな。
- 明日は gowatana さんの記事！楽しみ⸜(๑’ᵕ’๑)⸝
