🥇“ಕುಬರ್ನೆಟ್‌ಗಳು ಸುಪ್ತತೆಯನ್ನು 10 ಪಟ್ಟು ಹೆಚ್ಚಿಸಿದ್ದಾರೆ”: ಇದಕ್ಕೆ ಯಾರು ಹೊಣೆ?

ಸೂಚನೆ. ಅನುವಾದ.: ಯುರೋಪಿಯನ್ ಕಂಪನಿ ಅಡೆವಿಂಟಾದಲ್ಲಿ ಪ್ರಧಾನ ಸಾಫ್ಟ್‌ವೇರ್ ಇಂಜಿನಿಯರ್ ಹುದ್ದೆಯನ್ನು ಹೊಂದಿರುವ ಗ್ಯಾಲೋ ನವರೋ ಬರೆದ ಈ ಲೇಖನವು ಮೂಲಸೌಕರ್ಯ ಕಾರ್ಯಾಚರಣೆಗಳ ಕ್ಷೇತ್ರದಲ್ಲಿ ಆಕರ್ಷಕ ಮತ್ತು ಬೋಧಪ್ರದ "ತನಿಖೆ" ಆಗಿದೆ. ಲೇಖಕರು ಪ್ರಾರಂಭದಲ್ಲಿಯೇ ವಿವರಿಸುವ ಕಾರಣಕ್ಕಾಗಿ ಅದರ ಮೂಲ ಶೀರ್ಷಿಕೆಯನ್ನು ಅನುವಾದದಲ್ಲಿ ಸ್ವಲ್ಪ ವಿಸ್ತರಿಸಲಾಗಿದೆ.

ಲೇಖಕರಿಂದ ಟಿಪ್ಪಣಿ: ಈ ಪೋಸ್ಟ್ ತೋರುತ್ತಿದೆ ಆಕರ್ಷಿಸಿತು ನಿರೀಕ್ಷೆಗಿಂತ ಹೆಚ್ಚು ಗಮನ. ಲೇಖನದ ಶೀರ್ಷಿಕೆಯು ತಪ್ಪುದಾರಿಗೆಳೆಯುತ್ತಿದೆ ಮತ್ತು ಕೆಲವು ಓದುಗರು ದುಃಖಿತರಾಗಿದ್ದಾರೆ ಎಂಬ ಕೋಪದ ಕಾಮೆಂಟ್‌ಗಳು ನನಗೆ ಇನ್ನೂ ಬರುತ್ತವೆ. ಏನಾಗುತ್ತಿದೆ ಎಂಬುದಕ್ಕೆ ಕಾರಣಗಳನ್ನು ನಾನು ಅರ್ಥಮಾಡಿಕೊಂಡಿದ್ದೇನೆ, ಆದ್ದರಿಂದ, ಸಂಪೂರ್ಣ ಒಳಸಂಚುಗಳನ್ನು ಹಾಳುಮಾಡುವ ಅಪಾಯದ ಹೊರತಾಗಿಯೂ, ಈ ಲೇಖನದ ಬಗ್ಗೆ ನಾನು ತಕ್ಷಣವೇ ಹೇಳಲು ಬಯಸುತ್ತೇನೆ. ತಂಡಗಳು ಕುಬರ್ನೆಟ್ಸ್‌ಗೆ ವಲಸೆ ಹೋಗುತ್ತಿರುವಾಗ ನಾನು ನೋಡಿದ ಒಂದು ಕುತೂಹಲಕಾರಿ ಸಂಗತಿಯೆಂದರೆ, ಸಮಸ್ಯೆ ಉದ್ಭವಿಸಿದಾಗಲೆಲ್ಲಾ (ವಲಸೆಯ ನಂತರ ಹೆಚ್ಚಿದ ಸುಪ್ತತೆ), ಕುಬರ್ನೆಟ್ಸ್ ಅನ್ನು ದೂಷಿಸುವ ಮೊದಲ ವಿಷಯ, ಆದರೆ ಆರ್ಕೆಸ್ಟ್ರೇಟರ್ ನಿಜವಾಗಿಯೂ ಹಾಗೆ ಮಾಡುತ್ತಿಲ್ಲ ಎಂದು ಅದು ತಿರುಗುತ್ತದೆ. ದೂರುತ್ತಾರೆ. ಈ ಲೇಖನವು ಅಂತಹ ಒಂದು ಪ್ರಕರಣದ ಬಗ್ಗೆ ಹೇಳುತ್ತದೆ. ಇದರ ಹೆಸರು ನಮ್ಮ ಡೆವಲಪರ್‌ಗಳಲ್ಲಿ ಒಬ್ಬರ ಉದ್ಗಾರವನ್ನು ಪುನರಾವರ್ತಿಸುತ್ತದೆ (ನಂತರ ನೀವು ಕುಬರ್ನೆಟ್‌ಗಳಿಗೆ ಅದರೊಂದಿಗೆ ಯಾವುದೇ ಸಂಬಂಧವಿಲ್ಲ ಎಂದು ನೋಡುತ್ತೀರಿ). ನೀವು ಇಲ್ಲಿ ಕುಬರ್ನೆಟ್ಸ್ ಬಗ್ಗೆ ಯಾವುದೇ ಆಶ್ಚರ್ಯಕರ ಬಹಿರಂಗಪಡಿಸುವಿಕೆಯನ್ನು ಕಾಣುವುದಿಲ್ಲ, ಆದರೆ ಸಂಕೀರ್ಣ ವ್ಯವಸ್ಥೆಗಳ ಬಗ್ಗೆ ನೀವು ಒಂದೆರಡು ಉತ್ತಮ ಪಾಠಗಳನ್ನು ನಿರೀಕ್ಷಿಸಬಹುದು.

ಕೆಲವು ವಾರಗಳ ಹಿಂದೆ, ನನ್ನ ತಂಡವು CI/CD, ಕುಬರ್ನೆಟ್-ಆಧಾರಿತ ರನ್‌ಟೈಮ್, ಮೆಟ್ರಿಕ್‌ಗಳು ಮತ್ತು ಇತರ ಗುಡಿಗಳನ್ನು ಒಳಗೊಂಡಿರುವ ಕೋರ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗೆ ಒಂದೇ ಮೈಕ್ರೋ ಸರ್ವೀಸ್ ಅನ್ನು ಸ್ಥಳಾಂತರಿಸುತ್ತಿದೆ. ಈ ಕ್ರಮವು ಪ್ರಾಯೋಗಿಕ ಸ್ವರೂಪದ್ದಾಗಿತ್ತು: ನಾವು ಅದನ್ನು ಆಧಾರವಾಗಿ ತೆಗೆದುಕೊಳ್ಳಲು ಮತ್ತು ಮುಂಬರುವ ತಿಂಗಳುಗಳಲ್ಲಿ ಸರಿಸುಮಾರು 150 ಹೆಚ್ಚಿನ ಸೇವೆಗಳನ್ನು ವರ್ಗಾಯಿಸಲು ಯೋಜಿಸಿದ್ದೇವೆ. ಸ್ಪೇನ್‌ನಲ್ಲಿನ ಕೆಲವು ದೊಡ್ಡ ಆನ್‌ಲೈನ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗಳ ಕಾರ್ಯಾಚರಣೆಗೆ ಅವರೆಲ್ಲರೂ ಜವಾಬ್ದಾರರಾಗಿದ್ದಾರೆ (ಇನ್ಫೋಜಾಬ್ಸ್, ಫೋಟೊಕಾಸಾ, ಇತ್ಯಾದಿ.).

ನಾವು ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಕುಬರ್ನೆಟ್ಸ್‌ಗೆ ನಿಯೋಜಿಸಿದ ನಂತರ ಮತ್ತು ಅದಕ್ಕೆ ಸ್ವಲ್ಪ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಮರುನಿರ್ದೇಶಿಸಿದ ನಂತರ, ನಮಗೆ ಆತಂಕಕಾರಿ ಆಶ್ಚರ್ಯ ಕಾದಿತ್ತು. ವಿಳಂಬ (ಸುಪ್ತತೆ) ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿನ ವಿನಂತಿಗಳು EC10 ಗಿಂತ 2 ಪಟ್ಟು ಹೆಚ್ಚಾಗಿದೆ. ಸಾಮಾನ್ಯವಾಗಿ, ಈ ಸಮಸ್ಯೆಗೆ ಪರಿಹಾರವನ್ನು ಕಂಡುಹಿಡಿಯುವುದು ಅಥವಾ ಮೈಕ್ರೊ ಸರ್ವಿಸ್‌ನ ವಲಸೆಯನ್ನು ತ್ಯಜಿಸುವುದು ಅಗತ್ಯವಾಗಿತ್ತು (ಮತ್ತು, ಪ್ರಾಯಶಃ, ಸಂಪೂರ್ಣ ಯೋಜನೆ).

EC2 ಗಿಂತ ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿ ಸುಪ್ತತೆ ಏಕೆ ಹೆಚ್ಚು?

ಅಡಚಣೆಯನ್ನು ಕಂಡುಹಿಡಿಯಲು, ನಾವು ಸಂಪೂರ್ಣ ವಿನಂತಿಯ ಹಾದಿಯಲ್ಲಿ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸಿದ್ದೇವೆ. ನಮ್ಮ ಆರ್ಕಿಟೆಕ್ಚರ್ ಸರಳವಾಗಿದೆ: API ಗೇಟ್‌ವೇ (Zuul) ಪ್ರಾಕ್ಸಿಗಳು EC2 ಅಥವಾ Kubernetes ನಲ್ಲಿ ಮೈಕ್ರೋ ಸರ್ವೀಸ್ ನಿದರ್ಶನಗಳಿಗೆ ವಿನಂತಿಸುತ್ತದೆ. ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿ ನಾವು NGINX ಪ್ರವೇಶ ನಿಯಂತ್ರಕವನ್ನು ಬಳಸುತ್ತೇವೆ ಮತ್ತು ಬ್ಯಾಕೆಂಡ್‌ಗಳು ಸಾಮಾನ್ಯ ವಸ್ತುಗಳಾಗಿವೆ ನಿಯೋಜನೆ ಸ್ಪ್ರಿಂಗ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನಲ್ಲಿ JVM ಅಪ್ಲಿಕೇಶನ್‌ನೊಂದಿಗೆ.

                                  EC2
                            +---------------+
                            |  +---------+  |
                            |  |         |  |
                       +-------> BACKEND |  |
                       |    |  |         |  |
                       |    |  +---------+  |                   
                       |    +---------------+
             +------+  |
Public       |      |  |
      -------> ZUUL +--+
traffic      |      |  |              Kubernetes
             +------+  |    +-----------------------------+
                       |    |  +-------+      +---------+ |
                       |    |  |       |  xx  |         | |
                       +-------> NGINX +------> BACKEND | |
                            |  |       |  xx  |         | |
                            |  +-------+      +---------+ |
                            +-----------------------------+

ಸಮಸ್ಯೆಯು ಬ್ಯಾಕೆಂಡ್‌ನಲ್ಲಿನ ಆರಂಭಿಕ ಸುಪ್ತತೆಗೆ ಸಂಬಂಧಿಸಿದೆ ಎಂದು ತೋರುತ್ತಿದೆ (ನಾನು ಗ್ರಾಫ್‌ನಲ್ಲಿ ಸಮಸ್ಯೆಯ ಪ್ರದೇಶವನ್ನು "xx" ಎಂದು ಗುರುತಿಸಿದ್ದೇನೆ). EC2 ನಲ್ಲಿ, ಅಪ್ಲಿಕೇಶನ್ ಪ್ರತಿಕ್ರಿಯೆಯು ಸುಮಾರು 20ms ತೆಗೆದುಕೊಂಡಿತು. ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ, ಸುಪ್ತತೆಯು 100-200 ms ಗೆ ಹೆಚ್ಚಾಯಿತು.

ರನ್ಟೈಮ್ ಬದಲಾವಣೆಗೆ ಸಂಬಂಧಿಸಿದ ಶಂಕಿತರನ್ನು ನಾವು ತ್ವರಿತವಾಗಿ ವಜಾಗೊಳಿಸಿದ್ದೇವೆ. JVM ಆವೃತ್ತಿಯು ಒಂದೇ ಆಗಿರುತ್ತದೆ. ಕಂಟೈನರೈಸೇಶನ್ ಸಮಸ್ಯೆಗಳಿಗೂ ಇದರೊಂದಿಗೆ ಯಾವುದೇ ಸಂಬಂಧವಿಲ್ಲ: ಅಪ್ಲಿಕೇಶನ್ ಈಗಾಗಲೇ EC2 ನಲ್ಲಿ ಕಂಟೈನರ್‌ಗಳಲ್ಲಿ ಯಶಸ್ವಿಯಾಗಿ ಚಾಲನೆಯಲ್ಲಿದೆ. ಲೋಡ್ ಆಗುತ್ತಿದೆಯೇ? ಆದರೆ ನಾವು ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ 1 ವಿನಂತಿಯಲ್ಲೂ ಹೆಚ್ಚಿನ ಲೇಟೆನ್ಸಿಗಳನ್ನು ಗಮನಿಸಿದ್ದೇವೆ. ಕಸ ಸಂಗ್ರಹಣೆಗೆ ವಿರಾಮಗಳನ್ನು ಸಹ ನಿರ್ಲಕ್ಷಿಸಬಹುದು.

DNS ಪ್ರಶ್ನೆಗಳು ಈ ಹಿಂದೆ ಇದೇ ರೀತಿಯ ಸಮಸ್ಯೆಗಳನ್ನು ಉಂಟುಮಾಡಿದ್ದರಿಂದ ಅಪ್ಲಿಕೇಶನ್ ಬಾಹ್ಯ ಅವಲಂಬನೆಗಳನ್ನು ಹೊಂದಿದೆಯೇ ಎಂದು ನಮ್ಮ ಕುಬರ್ನೆಟ್ಸ್ ನಿರ್ವಾಹಕರೊಬ್ಬರು ಆಶ್ಚರ್ಯ ಪಡುತ್ತಾರೆ.

ಕಲ್ಪನೆ 1: DNS ಹೆಸರು ರೆಸಲ್ಯೂಶನ್

ಪ್ರತಿ ವಿನಂತಿಗಾಗಿ, ನಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ AWS ಸ್ಥಿತಿಸ್ಥಾಪಕ ಹುಡುಕಾಟದ ನಿದರ್ಶನವನ್ನು ಒಂದರಿಂದ ಮೂರು ಬಾರಿ ಡೊಮೇನ್‌ನಲ್ಲಿ ಪ್ರವೇಶಿಸುತ್ತದೆ elastic.spain.adevinta.com. ನಮ್ಮ ಪಾತ್ರೆಗಳ ಒಳಗೆ ಒಂದು ಶೆಲ್ ಇದೆ, ಆದ್ದರಿಂದ ಡೊಮೇನ್‌ಗಾಗಿ ಹುಡುಕಲು ನಿಜವಾಗಿಯೂ ಬಹಳ ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆಯೇ ಎಂದು ನಾವು ಪರಿಶೀಲಿಸಬಹುದು.

ಕಂಟೇನರ್‌ನಿಂದ DNS ಪ್ರಶ್ನೆಗಳು:

[root@be-851c76f696-alf8z /]# while true; do dig "elastic.spain.adevinta.com" | grep time; sleep 2; done
;; Query time: 22 msec
;; Query time: 22 msec
;; Query time: 29 msec
;; Query time: 21 msec
;; Query time: 28 msec
;; Query time: 43 msec
;; Query time: 39 msec

ಅಪ್ಲಿಕೇಶನ್ ಚಾಲನೆಯಲ್ಲಿರುವ EC2 ನಿದರ್ಶನಗಳಲ್ಲಿ ಒಂದರಿಂದ ಇದೇ ರೀತಿಯ ವಿನಂತಿಗಳು:

bash-4.4# while true; do dig "elastic.spain.adevinta.com" | grep time; sleep 2; done
;; Query time: 77 msec
;; Query time: 0 msec
;; Query time: 0 msec
;; Query time: 0 msec
;; Query time: 0 msec

ಲುಕಪ್ ಸುಮಾರು 30ms ತೆಗೆದುಕೊಂಡಿದೆ ಎಂದು ಪರಿಗಣಿಸಿ, ಸ್ಥಿತಿಸ್ಥಾಪಕ ಹುಡುಕಾಟವನ್ನು ಪ್ರವೇಶಿಸುವಾಗ DNS ರೆಸಲ್ಯೂಶನ್ ನಿಜವಾಗಿಯೂ ಸುಪ್ತತೆಯ ಹೆಚ್ಚಳಕ್ಕೆ ಕೊಡುಗೆ ನೀಡುತ್ತಿದೆ ಎಂಬುದು ಸ್ಪಷ್ಟವಾಯಿತು.

ಆದಾಗ್ಯೂ, ಇದು ಎರಡು ಕಾರಣಗಳಿಗಾಗಿ ವಿಚಿತ್ರವಾಗಿತ್ತು:

ಹೆಚ್ಚಿನ ಲೇಟೆನ್ಸಿಯಿಂದ ಬಳಲದೆ AWS ಸಂಪನ್ಮೂಲಗಳೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸುವ ಟನ್ ಕುಬರ್ನೆಟ್ಸ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ನಾವು ಈಗಾಗಲೇ ಹೊಂದಿದ್ದೇವೆ. ಕಾರಣ ಏನೇ ಇರಲಿ, ಇದು ಈ ಪ್ರಕರಣಕ್ಕೆ ನಿರ್ದಿಷ್ಟವಾಗಿ ಸಂಬಂಧಿಸಿದೆ.
JVM ಇನ್-ಮೆಮೊರಿ DNS ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುತ್ತದೆ ಎಂದು ನಮಗೆ ತಿಳಿದಿದೆ. ನಮ್ಮ ಚಿತ್ರಗಳಲ್ಲಿ, TTL ಮೌಲ್ಯವನ್ನು ಬರೆಯಲಾಗಿದೆ $JAVA_HOME/jre/lib/security/java.security ಮತ್ತು 10 ಸೆಕೆಂಡುಗಳಿಗೆ ಹೊಂದಿಸಿ: networkaddress.cache.ttl = 10. ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಹೇಳುವುದಾದರೆ, JVM ಎಲ್ಲಾ DNS ಪ್ರಶ್ನೆಗಳನ್ನು 10 ಸೆಕೆಂಡುಗಳವರೆಗೆ ಸಂಗ್ರಹಿಸಬೇಕು.

ಮೊದಲ ಊಹೆಯನ್ನು ದೃಢೀಕರಿಸಲು, ನಾವು ಸ್ವಲ್ಪ ಸಮಯದವರೆಗೆ DNS ಗೆ ಕರೆ ಮಾಡುವುದನ್ನು ನಿಲ್ಲಿಸಲು ನಿರ್ಧರಿಸಿದ್ದೇವೆ ಮತ್ತು ಸಮಸ್ಯೆ ದೂರವಾಗಿದೆಯೇ ಎಂದು ನೋಡಲು ನಿರ್ಧರಿಸಿದೆವು. ಮೊದಲಿಗೆ, ನಾವು ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಮರುಸಂರಚಿಸಲು ನಿರ್ಧರಿಸಿದ್ದೇವೆ ಇದರಿಂದ ಅದು ಡೊಮೇನ್ ಹೆಸರಿನ ಮೂಲಕ ಬದಲಿಗೆ IP ವಿಳಾಸದ ಮೂಲಕ Elasticsearch ನೊಂದಿಗೆ ನೇರವಾಗಿ ಸಂವಹನ ನಡೆಸುತ್ತದೆ. ಇದಕ್ಕೆ ಕೋಡ್ ಬದಲಾವಣೆಗಳು ಮತ್ತು ಹೊಸ ನಿಯೋಜನೆಯ ಅಗತ್ಯವಿರುತ್ತದೆ, ಆದ್ದರಿಂದ ನಾವು ಡೊಮೇನ್ ಅನ್ನು ಅದರ IP ವಿಳಾಸಕ್ಕೆ ಮ್ಯಾಪ್ ಮಾಡಿದ್ದೇವೆ /etc/hosts:

34.55.5.111 elastic.spain.adevinta.com

ಈಗ ಕಂಟೇನರ್ ಬಹುತೇಕ ತಕ್ಷಣವೇ IP ಅನ್ನು ಸ್ವೀಕರಿಸಿದೆ. ಇದು ಕೆಲವು ಸುಧಾರಣೆಗೆ ಕಾರಣವಾಯಿತು, ಆದರೆ ನಾವು ನಿರೀಕ್ಷಿತ ಲೇಟೆನ್ಸಿ ಮಟ್ಟಗಳಿಗೆ ಸ್ವಲ್ಪ ಹತ್ತಿರವಾಗಿದ್ದೇವೆ. DNS ರೆಸಲ್ಯೂಶನ್ ಬಹಳ ಸಮಯ ತೆಗೆದುಕೊಂಡರೂ, ನಿಜವಾದ ಕಾರಣ ನಮಗೆ ಇನ್ನೂ ತಪ್ಪಿಸಿಕೊಂಡಿದೆ.

ನೆಟ್ವರ್ಕ್ ಮೂಲಕ ರೋಗನಿರ್ಣಯ

ಬಳಸಿ ಕಂಟೇನರ್‌ನಿಂದ ದಟ್ಟಣೆಯನ್ನು ವಿಶ್ಲೇಷಿಸಲು ನಾವು ನಿರ್ಧರಿಸಿದ್ದೇವೆ tcpdumpನೆಟ್ವರ್ಕ್ನಲ್ಲಿ ನಿಖರವಾಗಿ ಏನಾಗುತ್ತಿದೆ ಎಂಬುದನ್ನು ನೋಡಲು:

[root@be-851c76f696-alf8z /]# tcpdump -leni any -w capture.pcap

ನಾವು ನಂತರ ಹಲವಾರು ವಿನಂತಿಗಳನ್ನು ಕಳುಹಿಸಿದ್ದೇವೆ ಮತ್ತು ಅವುಗಳ ಸೆರೆಹಿಡಿಯುವಿಕೆಯನ್ನು ಡೌನ್‌ಲೋಡ್ ಮಾಡಿದ್ದೇವೆ (kubectl cp my-service:/capture.pcap capture.pcap) ಹೆಚ್ಚಿನ ವಿಶ್ಲೇಷಣೆಗಾಗಿ ವೈರ್ಷಾರ್ಕ್.

DNS ಪ್ರಶ್ನೆಗಳ ಬಗ್ಗೆ ಅನುಮಾನಾಸ್ಪದ ಏನೂ ಇರಲಿಲ್ಲ (ನಾನು ನಂತರ ಮಾತನಾಡುವ ಒಂದು ಸಣ್ಣ ವಿಷಯವನ್ನು ಹೊರತುಪಡಿಸಿ). ಆದರೆ ನಮ್ಮ ಸೇವೆಯು ಪ್ರತಿ ವಿನಂತಿಯನ್ನು ನಿರ್ವಹಿಸುವ ರೀತಿಯಲ್ಲಿ ಕೆಲವು ವಿಚಿತ್ರತೆಗಳಿವೆ. ಪ್ರತಿಕ್ರಿಯೆ ಪ್ರಾರಂಭವಾಗುವ ಮೊದಲು ವಿನಂತಿಯನ್ನು ಸ್ವೀಕರಿಸಲಾಗಿದೆ ಎಂದು ತೋರಿಸುವ ಕ್ಯಾಪ್ಚರ್‌ನ ಸ್ಕ್ರೀನ್‌ಶಾಟ್ ಕೆಳಗೆ ಇದೆ:

ಮೊದಲ ಕಾಲಂನಲ್ಲಿ ಪ್ಯಾಕೇಜ್ ಸಂಖ್ಯೆಗಳನ್ನು ತೋರಿಸಲಾಗಿದೆ. ಸ್ಪಷ್ಟತೆಗಾಗಿ, ನಾನು ವಿಭಿನ್ನ TCP ಹರಿವುಗಳನ್ನು ಬಣ್ಣ-ಕೋಡೆಡ್ ಮಾಡಿದ್ದೇನೆ.

ಪ್ಯಾಕೆಟ್ 328 ರಿಂದ ಪ್ರಾರಂಭವಾಗುವ ಹಸಿರು ಸ್ಟ್ರೀಮ್ ಕ್ಲೈಂಟ್ (172.17.22.150) ಕಂಟೇನರ್‌ಗೆ (172.17.36.147) TCP ಸಂಪರ್ಕವನ್ನು ಹೇಗೆ ಸ್ಥಾಪಿಸಿದೆ ಎಂಬುದನ್ನು ತೋರಿಸುತ್ತದೆ. ಆರಂಭಿಕ ಹ್ಯಾಂಡ್ಶೇಕ್ (328-330) ನಂತರ, ಪ್ಯಾಕೇಜ್ 331 ಅನ್ನು ತರಲಾಯಿತು HTTP GET /v1/.. - ನಮ್ಮ ಸೇವೆಗೆ ಒಳಬರುವ ವಿನಂತಿ. ಇಡೀ ಪ್ರಕ್ರಿಯೆಯು 1 ms ತೆಗೆದುಕೊಂಡಿತು.

ಗ್ರೇ ಸ್ಟ್ರೀಮ್ (ಪ್ಯಾಕೆಟ್ 339 ರಿಂದ) ನಮ್ಮ ಸೇವೆಯು ಸ್ಥಿತಿಸ್ಥಾಪಕ ಹುಡುಕಾಟ ನಿದರ್ಶನಕ್ಕೆ HTTP ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸಿದೆ ಎಂದು ತೋರಿಸುತ್ತದೆ (ಯಾವುದೇ TCP ಹ್ಯಾಂಡ್‌ಶೇಕ್ ಇಲ್ಲ ಏಕೆಂದರೆ ಅದು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಸಂಪರ್ಕವನ್ನು ಬಳಸುತ್ತಿದೆ). ಇದು 18ms ತೆಗೆದುಕೊಂಡಿತು.

ಇಲ್ಲಿಯವರೆಗೆ ಎಲ್ಲವೂ ಉತ್ತಮವಾಗಿದೆ, ಮತ್ತು ಸಮಯವು ನಿರೀಕ್ಷಿತ ವಿಳಂಬಗಳಿಗೆ ಸರಿಸುಮಾರು ಅನುರೂಪವಾಗಿದೆ (ಕ್ಲೈಂಟ್ನಿಂದ ಅಳತೆ ಮಾಡಿದಾಗ 20-30 ms).

ಆದಾಗ್ಯೂ, ನೀಲಿ ವಿಭಾಗವು 86ms ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಅದರಲ್ಲಿ ಏನು ನಡೆಯುತ್ತಿದೆ? ಪ್ಯಾಕೆಟ್ 333 ನೊಂದಿಗೆ, ನಮ್ಮ ಸೇವೆಯು HTTP GET ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸಿದೆ /latest/meta-data/iam/security-credentials, ಮತ್ತು ಅದರ ನಂತರ, ಅದೇ TCP ಸಂಪರ್ಕದ ಮೂಲಕ, ಮತ್ತೊಂದು GET ವಿನಂತಿಯನ್ನು /latest/meta-data/iam/security-credentials/arn:...

ಟ್ರೇಸ್‌ನಾದ್ಯಂತ ಪ್ರತಿ ವಿನಂತಿಯೊಂದಿಗೆ ಇದು ಪುನರಾವರ್ತನೆಯಾಗುತ್ತದೆ ಎಂದು ನಾವು ಕಂಡುಕೊಂಡಿದ್ದೇವೆ. DNS ರೆಸಲ್ಯೂಶನ್ ನಮ್ಮ ಕಂಟೇನರ್‌ಗಳಲ್ಲಿ ಸ್ವಲ್ಪ ನಿಧಾನವಾಗಿರುತ್ತದೆ (ಈ ವಿದ್ಯಮಾನದ ವಿವರಣೆಯು ಸಾಕಷ್ಟು ಆಸಕ್ತಿದಾಯಕವಾಗಿದೆ, ಆದರೆ ನಾನು ಅದನ್ನು ಪ್ರತ್ಯೇಕ ಲೇಖನಕ್ಕಾಗಿ ಉಳಿಸುತ್ತೇನೆ). ಪ್ರತಿ ವಿನಂತಿಯ ಮೇಲೆ AWS ಇನ್‌ಸ್ಟಾನ್ಸ್ ಮೆಟಾಡೇಟಾ ಸೇವೆಗೆ ಕರೆಗಳು ದೀರ್ಘ ವಿಳಂಬಕ್ಕೆ ಕಾರಣ ಎಂದು ಅದು ಬದಲಾಯಿತು.

ಕಲ್ಪನೆ 2: AWS ಗೆ ಅನಗತ್ಯ ಕರೆಗಳು

ಎರಡೂ ಅಂತಿಮ ಬಿಂದುಗಳು ಸೇರಿವೆ AWS ನಿದರ್ಶನ ಮೆಟಾಡೇಟಾ API. Elasticsearch ಅನ್ನು ಚಾಲನೆ ಮಾಡುವಾಗ ನಮ್ಮ ಮೈಕ್ರೋ ಸರ್ವೀಸ್ ಈ ಸೇವೆಯನ್ನು ಬಳಸುತ್ತದೆ. ಎರಡೂ ಕರೆಗಳು ಮೂಲಭೂತ ಅಧಿಕಾರ ಪ್ರಕ್ರಿಯೆಯ ಭಾಗವಾಗಿದೆ. ಮೊದಲ ವಿನಂತಿಯಲ್ಲಿ ಪ್ರವೇಶಿಸಿದ ಅಂತಿಮ ಬಿಂದುವು ನಿದರ್ಶನದೊಂದಿಗೆ ಸಂಬಂಧಿಸಿದ IAM ಪಾತ್ರವನ್ನು ನೀಡುತ್ತದೆ.

/ # curl http://169.254.169.254/latest/meta-data/iam/security-credentials/
arn:aws:iam::<account_id>:role/some_role

ಎರಡನೇ ವಿನಂತಿಯು ಈ ನಿದರ್ಶನಕ್ಕಾಗಿ ತಾತ್ಕಾಲಿಕ ಅನುಮತಿಗಳಿಗಾಗಿ ಎರಡನೇ ಅಂತಿಮ ಬಿಂದುವನ್ನು ಕೇಳುತ್ತದೆ:

/ # curl http://169.254.169.254/latest/meta-data/iam/security-credentials/arn:aws:iam::<account_id>:role/some_role`
{
    "Code" : "Success",
    "LastUpdated" : "2012-04-26T16:39:16Z",
    "Type" : "AWS-HMAC",
    "AccessKeyId" : "ASIAIOSFODNN7EXAMPLE",
    "SecretAccessKey" : "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
    "Token" : "token",
    "Expiration" : "2017-05-17T15:09:54Z"
}

ಕ್ಲೈಂಟ್ ಅವುಗಳನ್ನು ಅಲ್ಪಾವಧಿಗೆ ಬಳಸಬಹುದು ಮತ್ತು ನಿಯತಕಾಲಿಕವಾಗಿ ಹೊಸ ಪ್ರಮಾಣಪತ್ರಗಳನ್ನು ಪಡೆಯಬೇಕು (ಅವುಗಳ ಮೊದಲು Expiration) ಮಾದರಿಯು ಸರಳವಾಗಿದೆ: ಭದ್ರತಾ ಕಾರಣಗಳಿಗಾಗಿ AWS ತಾತ್ಕಾಲಿಕ ಕೀಗಳನ್ನು ಆಗಾಗ್ಗೆ ತಿರುಗಿಸುತ್ತದೆ, ಆದರೆ ಹೊಸ ಪ್ರಮಾಣಪತ್ರಗಳನ್ನು ಪಡೆಯುವಲ್ಲಿ ಸಂಬಂಧಿಸಿದ ಕಾರ್ಯಕ್ಷಮತೆಯ ದಂಡವನ್ನು ಸರಿದೂಗಿಸಲು ಗ್ರಾಹಕರು ಅವುಗಳನ್ನು ಕೆಲವು ನಿಮಿಷಗಳವರೆಗೆ ಸಂಗ್ರಹಿಸಬಹುದು.

AWS Java SDK ಈ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಸಂಘಟಿಸುವ ಜವಾಬ್ದಾರಿಯನ್ನು ತೆಗೆದುಕೊಳ್ಳಬೇಕು, ಆದರೆ ಕೆಲವು ಕಾರಣಗಳಿಂದ ಇದು ಸಂಭವಿಸುವುದಿಲ್ಲ.

GitHub ನಲ್ಲಿ ಸಮಸ್ಯೆಗಳನ್ನು ಹುಡುಕಿದ ನಂತರ, ನಾವು ಸಮಸ್ಯೆಯನ್ನು ಎದುರಿಸಿದ್ದೇವೆ #1921. ಮತ್ತಷ್ಟು "ಡಿಗ್" ಮಾಡುವ ದಿಕ್ಕನ್ನು ನಿರ್ಧರಿಸಲು ಅವಳು ನಮಗೆ ಸಹಾಯ ಮಾಡಿದಳು.

ಕೆಳಗಿನ ಷರತ್ತುಗಳಲ್ಲಿ ಒಂದಾದಾಗ AWS SDK ಪ್ರಮಾಣಪತ್ರಗಳನ್ನು ನವೀಕರಿಸುತ್ತದೆ:

ಮುಕ್ತಾಯ ದಿನಾಂಕ (Expiration) ಸೇರುತ್ತವೆ EXPIRATION_THRESHOLD, 15 ನಿಮಿಷಗಳವರೆಗೆ ಹಾರ್ಡ್‌ಕೋಡ್ ಮಾಡಲಾಗಿದೆ.
ಪ್ರಮಾಣಪತ್ರಗಳನ್ನು ನವೀಕರಿಸುವ ಕೊನೆಯ ಪ್ರಯತ್ನದಿಂದ ಹೆಚ್ಚು ಸಮಯ ಕಳೆದಿದೆ REFRESH_THRESHOLD, 60 ನಿಮಿಷಗಳ ಕಾಲ ಹಾರ್ಡ್‌ಕೋಡ್ ಮಾಡಲಾಗಿದೆ.

ನಾವು ಸ್ವೀಕರಿಸುವ ಪ್ರಮಾಣಪತ್ರಗಳ ನಿಜವಾದ ಮುಕ್ತಾಯ ದಿನಾಂಕವನ್ನು ನೋಡಲು, ನಾವು ಕಂಟೇನರ್ ಮತ್ತು EC2 ನಿದರ್ಶನ ಎರಡರಿಂದಲೂ ಮೇಲಿನ ಕರ್ಲ್ ಕಮಾಂಡ್‌ಗಳನ್ನು ರನ್ ಮಾಡಿದ್ದೇವೆ. ಕಂಟೇನರ್‌ನಿಂದ ಸ್ವೀಕರಿಸಿದ ಪ್ರಮಾಣಪತ್ರದ ಮಾನ್ಯತೆಯ ಅವಧಿಯು ಹೆಚ್ಚು ಕಡಿಮೆಯಾಗಿದೆ: ನಿಖರವಾಗಿ 15 ನಿಮಿಷಗಳು.

ಈಗ ಎಲ್ಲವೂ ಸ್ಪಷ್ಟವಾಗಿದೆ: ಮೊದಲ ವಿನಂತಿಗಾಗಿ, ನಮ್ಮ ಸೇವೆಯು ತಾತ್ಕಾಲಿಕ ಪ್ರಮಾಣಪತ್ರಗಳನ್ನು ಸ್ವೀಕರಿಸಿದೆ. ಅವು 15 ನಿಮಿಷಗಳಿಗಿಂತ ಹೆಚ್ಚು ಕಾಲ ಮಾನ್ಯವಾಗಿಲ್ಲದ ಕಾರಣ, AWS SDK ನಂತರದ ವಿನಂತಿಯ ಮೇರೆಗೆ ಅವುಗಳನ್ನು ನವೀಕರಿಸಲು ನಿರ್ಧರಿಸುತ್ತದೆ. ಮತ್ತು ಇದು ಪ್ರತಿ ವಿನಂತಿಯೊಂದಿಗೆ ಸಂಭವಿಸಿತು.

ಪ್ರಮಾಣಪತ್ರಗಳ ಮಾನ್ಯತೆಯ ಅವಧಿ ಏಕೆ ಕಡಿಮೆಯಾಗಿದೆ?

AWS ನಿದರ್ಶನ ಮೆಟಾಡೇಟಾವನ್ನು EC2 ನಿದರ್ಶನಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ, ಕುಬರ್ನೆಟ್ಸ್ ಅಲ್ಲ. ಮತ್ತೊಂದೆಡೆ, ನಾವು ಅಪ್ಲಿಕೇಶನ್ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಬದಲಾಯಿಸಲು ಬಯಸುವುದಿಲ್ಲ. ಇದಕ್ಕಾಗಿ ನಾವು ಬಳಸಿದ್ದೇವೆ KIAM - ಪ್ರತಿ ಕುಬರ್ನೆಟ್ಸ್ ನೋಡ್‌ನಲ್ಲಿ ಏಜೆಂಟ್‌ಗಳನ್ನು ಬಳಸಿಕೊಂಡು, ಬಳಕೆದಾರರಿಗೆ (ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಕ್ಲಸ್ಟರ್‌ಗೆ ನಿಯೋಜಿಸುವ ಎಂಜಿನಿಯರ್‌ಗಳು) ಪಾಡ್‌ಗಳಲ್ಲಿನ ಕಂಟೈನರ್‌ಗಳಿಗೆ EC2 ನಿದರ್ಶನಗಳಂತೆ IAM ಪಾತ್ರಗಳನ್ನು ನಿಯೋಜಿಸಲು ಅನುಮತಿಸುವ ಸಾಧನ. KIAM AWS ಇನ್‌ಸ್ಟಾನ್ಸ್ ಮೆಟಾಡೇಟಾ ಸೇವೆಗೆ ಕರೆಗಳನ್ನು ತಡೆಹಿಡಿಯುತ್ತದೆ ಮತ್ತು ಹಿಂದೆ AWS ನಿಂದ ಸ್ವೀಕರಿಸಿದ ನಂತರ ಅದರ ಸಂಗ್ರಹದಿಂದ ಅವುಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತದೆ. ಅಪ್ಲಿಕೇಶನ್ ದೃಷ್ಟಿಕೋನದಿಂದ, ಏನೂ ಬದಲಾಗುವುದಿಲ್ಲ.

KIAM ಪಾಡ್‌ಗಳಿಗೆ ಅಲ್ಪಾವಧಿಯ ಪ್ರಮಾಣಪತ್ರಗಳನ್ನು ಪೂರೈಸುತ್ತದೆ. ಪಾಡ್‌ನ ಸರಾಸರಿ ಜೀವಿತಾವಧಿಯು EC2 ನಿದರ್ಶನಕ್ಕಿಂತ ಚಿಕ್ಕದಾಗಿದೆ ಎಂದು ಪರಿಗಣಿಸಿ ಇದು ಅರ್ಥಪೂರ್ಣವಾಗಿದೆ. ಪ್ರಮಾಣಪತ್ರಗಳಿಗೆ ಡೀಫಾಲ್ಟ್ ಮಾನ್ಯತೆಯ ಅವಧಿ ಅದೇ 15 ನಿಮಿಷಗಳಿಗೆ ಸಮಾನವಾಗಿರುತ್ತದೆ.

ಪರಿಣಾಮವಾಗಿ, ನೀವು ಎರಡೂ ಡೀಫಾಲ್ಟ್ ಮೌಲ್ಯಗಳನ್ನು ಒಂದರ ಮೇಲೊಂದರಂತೆ ಒವರ್ಲೆ ಮಾಡಿದರೆ, ಸಮಸ್ಯೆ ಉದ್ಭವಿಸುತ್ತದೆ. ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಒದಗಿಸಲಾದ ಪ್ರತಿ ಪ್ರಮಾಣಪತ್ರವು 15 ನಿಮಿಷಗಳ ನಂತರ ಮುಕ್ತಾಯಗೊಳ್ಳುತ್ತದೆ. ಆದಾಗ್ಯೂ, AWS Java SDK ಅದರ ಮುಕ್ತಾಯ ದಿನಾಂಕಕ್ಕಿಂತ 15 ನಿಮಿಷಗಳಿಗಿಂತ ಕಡಿಮೆ ಉಳಿದಿರುವ ಯಾವುದೇ ಪ್ರಮಾಣಪತ್ರದ ನವೀಕರಣವನ್ನು ಒತ್ತಾಯಿಸುತ್ತದೆ.

ಪರಿಣಾಮವಾಗಿ, ತಾತ್ಕಾಲಿಕ ಪ್ರಮಾಣಪತ್ರವನ್ನು ಪ್ರತಿ ವಿನಂತಿಯೊಂದಿಗೆ ನವೀಕರಿಸಲು ಒತ್ತಾಯಿಸಲಾಗುತ್ತದೆ, ಇದು AWS API ಗೆ ಒಂದೆರಡು ಕರೆಗಳನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ ಮತ್ತು ಸುಪ್ತತೆಯಲ್ಲಿ ಗಮನಾರ್ಹ ಹೆಚ್ಚಳಕ್ಕೆ ಕಾರಣವಾಗುತ್ತದೆ. AWS ಜಾವಾ SDK ನಲ್ಲಿ ನಾವು ಕಂಡುಕೊಂಡಿದ್ದೇವೆ ವೈಶಿಷ್ಟ್ಯ ವಿನಂತಿ, ಇದು ಇದೇ ರೀತಿಯ ಸಮಸ್ಯೆಯನ್ನು ಉಲ್ಲೇಖಿಸುತ್ತದೆ.

ಪರಿಹಾರವು ಸರಳವಾಗಿದೆ ಎಂದು ಬದಲಾಯಿತು. ದೀರ್ಘಾವಧಿಯ ಅವಧಿಯೊಂದಿಗೆ ಪ್ರಮಾಣಪತ್ರಗಳನ್ನು ವಿನಂತಿಸಲು ನಾವು KIAM ಅನ್ನು ಸರಳವಾಗಿ ಮರುಸಂರಚಿಸಿದ್ದೇವೆ. ಇದು ಸಂಭವಿಸಿದ ನಂತರ, AWS ಮೆಟಾಡೇಟಾ ಸೇವೆಯ ಭಾಗವಹಿಸುವಿಕೆ ಇಲ್ಲದೆ ವಿನಂತಿಗಳು ಹರಿಯಲು ಪ್ರಾರಂಭಿಸಿದವು ಮತ್ತು ಸುಪ್ತತೆಯು EC2 ಗಿಂತ ಕಡಿಮೆ ಮಟ್ಟಕ್ಕೆ ಇಳಿಯಿತು.

ಸಂಶೋಧನೆಗಳು

ವಲಸೆಯೊಂದಿಗಿನ ನಮ್ಮ ಅನುಭವದ ಆಧಾರದ ಮೇಲೆ, ಕುಬರ್ನೆಟ್ಸ್ ಅಥವಾ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನ ಇತರ ಅಂಶಗಳಲ್ಲಿನ ದೋಷಗಳು ಸಮಸ್ಯೆಗಳ ಸಾಮಾನ್ಯ ಮೂಲಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ. ನಾವು ಪೋರ್ಟ್ ಮಾಡುತ್ತಿರುವ ಮೈಕ್ರೋ ಸರ್ವೀಸ್‌ಗಳಲ್ಲಿನ ಯಾವುದೇ ಮೂಲಭೂತ ನ್ಯೂನತೆಗಳನ್ನು ಸಹ ಇದು ಪರಿಹರಿಸುವುದಿಲ್ಲ. ನಾವು ವಿಭಿನ್ನ ಅಂಶಗಳನ್ನು ಒಟ್ಟಿಗೆ ಸೇರಿಸುವುದರಿಂದ ಸಮಸ್ಯೆಗಳು ಹೆಚ್ಚಾಗಿ ಉದ್ಭವಿಸುತ್ತವೆ.

ಹಿಂದೆಂದೂ ಪರಸ್ಪರ ಸಂವಹನ ನಡೆಸದ ಸಂಕೀರ್ಣ ವ್ಯವಸ್ಥೆಗಳನ್ನು ನಾವು ಒಟ್ಟಿಗೆ ಬೆರೆಸುತ್ತೇವೆ, ಒಟ್ಟಿಗೆ ಅವು ಒಂದೇ, ದೊಡ್ಡ ವ್ಯವಸ್ಥೆಯನ್ನು ರೂಪಿಸುತ್ತವೆ ಎಂದು ನಿರೀಕ್ಷಿಸುತ್ತೇವೆ. ಅಯ್ಯೋ, ಹೆಚ್ಚಿನ ಅಂಶಗಳು, ದೋಷಗಳಿಗೆ ಹೆಚ್ಚು ಸ್ಥಳಾವಕಾಶ, ಹೆಚ್ಚಿನ ಎಂಟ್ರೊಪಿ.

ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ, ಹೆಚ್ಚಿನ ಸುಪ್ತತೆಯು ಕುಬರ್ನೆಟ್ಸ್, KIAM, AWS Java SDK ಅಥವಾ ನಮ್ಮ ಮೈಕ್ರೋ ಸರ್ವಿಸ್‌ನಲ್ಲಿನ ದೋಷಗಳು ಅಥವಾ ಕೆಟ್ಟ ನಿರ್ಧಾರಗಳ ಪರಿಣಾಮವಲ್ಲ. ಇದು ಎರಡು ಸ್ವತಂತ್ರ ಡೀಫಾಲ್ಟ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಸಂಯೋಜಿಸುವ ಫಲಿತಾಂಶವಾಗಿದೆ: ಒಂದು KIAM ನಲ್ಲಿ, ಇನ್ನೊಂದು AWS ಜಾವಾ SDK ನಲ್ಲಿ. ಪ್ರತ್ಯೇಕವಾಗಿ ತೆಗೆದುಕೊಂಡರೆ, ಎರಡೂ ನಿಯತಾಂಕಗಳು ಅರ್ಥಪೂರ್ಣವಾಗಿವೆ: AWS Java SDK ನಲ್ಲಿ ಸಕ್ರಿಯ ಪ್ರಮಾಣಪತ್ರ ನವೀಕರಣ ನೀತಿ, ಮತ್ತು KAIM ನಲ್ಲಿ ಪ್ರಮಾಣಪತ್ರಗಳ ಕಡಿಮೆ ಅವಧಿಯ ಅವಧಿ. ಆದರೆ ನೀವು ಅವುಗಳನ್ನು ಒಟ್ಟಿಗೆ ಸೇರಿಸಿದಾಗ, ಫಲಿತಾಂಶಗಳು ಅನಿರೀಕ್ಷಿತವಾಗುತ್ತವೆ. ಎರಡು ಸ್ವತಂತ್ರ ಮತ್ತು ತಾರ್ಕಿಕ ಪರಿಹಾರಗಳನ್ನು ಸಂಯೋಜಿಸಿದಾಗ ಅರ್ಥವಿಲ್ಲ.

ಅನುವಾದಕರಿಂದ PS

AWS IAM ಅನ್ನು Kubernetes ನೊಂದಿಗೆ ಸಂಯೋಜಿಸಲು KIAM ಯುಟಿಲಿಟಿಯ ವಾಸ್ತುಶಿಲ್ಪದ ಬಗ್ಗೆ ನೀವು ಇನ್ನಷ್ಟು ತಿಳಿದುಕೊಳ್ಳಬಹುದು ಈ ಲೇಖನ ಅದರ ಸೃಷ್ಟಿಕರ್ತರಿಂದ.

ನಮ್ಮ ಬ್ಲಾಗ್‌ನಲ್ಲಿ ಸಹ ಓದಿ:

ಮೂಲ: www.habr.com

"ಕುಬರ್ನೆಟ್ಸ್ ಸುಪ್ತತೆಯನ್ನು 10 ಪಟ್ಟು ಹೆಚ್ಚಿಸಿದ್ದಾರೆ": ಇದಕ್ಕೆ ಯಾರು ಹೊಣೆ?