YABOONG

Low Wing Airplane Maneuver Tips - Steep Spiral

Fri, 13 Feb 2026 00:00:00 +0000

Intro

Personally, I find the Steep Spiral to be one of the most challenging maneuvers.
After plenty of trial and error in X-Plane, I’ve finally had a bit of a breakthrough.
I’ve put together some insights and tips that I believe will make your training much more effective.

Disclaimer

⚠️ This is for educational and entertainment purposes only. I am not a certified flight instructor (CFI). Do not use this as a substitute for professional flight training. Always consult a CFI and follow your aircraft’s POH. I accept no liability for any actions taken based on this content.

TL;DR

Short on time? Just watch this.

GS < 80: Use a 30° bank. (Don’t go much lower than this, or the radius gets too wide.)
GS = 90–95: Stick to the 45° baseline.
GS > 110: Increase to a 55° bank (But remember, never exceed 60°).

More GS, More Bank, More Back Pressure
Less GS, Less Bank, Less Back Pressure

Why the Steep Spiral is So Challenging

At first, I thought it was just a combination of Turns Around a Point and an Emergency Descent—both maneuvers I practiced during my Private Pilot training. I figured I just had to keep the wingtip on the reference point while descending rapidly, all while staying within bank and airspeed limits. It seemed simple enough in my head, but the reality was quite different.

1. How much bank is enough?

The ACS states, “Establish and maintain a steep spiral, not to exceed 60° angle of bank.” But does that mean anything under 60° is fine? Is 45° steep enough? What about 35° or 20°? The real challenge is maintaining a constant radius about a ground reference point. Finding that perfect balance between a specific bank angle and a consistent radius was personally the hardest part for me.

ACS Steep Spiral

2. What about the airspeed?

The ACS allows a margin of ±10 knots, but ±10 knots from what exactly? Best glide speed? maneuvering speed? or just 90kts? 100kts?

3. Time and Cost

The ACS requires completing the maneuver no lower than 1,500 feet AGL, and since you have to perform three full 360-degree turns, you need plenty of altitude. Even with a conservative estimate of 1,000 feet per turn, you need to start at least at 4,500 feet AGL. My instructor prefers starting at 5,500 feet MSL (airport elevation 120ft MSL) for an extra margin of safety. Because you have to climb so high for every single attempt, this maneuver consumes significantly more time and money compared to others.

4. Different Perspectives (Left vs. Right Seat)

The view of the ground reference point is completely different for the student in the left seat and the instructor in the right. Because of these different angles, it’s hard for the instructor to give precise advice based on exactly what I’m seeing at that moment.

5. The “Low Wing” Struggle

In a low-wing aircraft, the wing often blocks the very ground reference you’re trying to follow. Maintaining visual contact throughout the entire 360-degree turn is much more difficult than it looks.

6. Coriolis Illusion

During a steady steep turn, the fluid in your inner ear stabilizes. If you suddenly move your head to check your GS on the instruments and then look back out at the reference point, it can trigger the Coriolis Illusion.

7. Constantly Shifting Winds

Not only does the wind direction relative to the nose change as you turn, but the wind speed and direction also shift as you descend to lower altitudes. You have to account for these changes constantly.

8. Everything Happens So Fast

As always in aviation, everything happens in a flash. There are so many variables changing at once that if you miss a small correction window, the whole maneuver can fall apart before you know it.

Airplane Flying Handbook

Update: This section has been updated based on feedback from a reader.
Thanks to “SeoulCitizen”! (See what’s updated: ee0d373)

Let’s look at what the FAA Airplane Flying Handbook (AFH) says about the Steep Spiral.

Airplane Flying Handbook 10-3

The handbook uses key phrases such as “rapidly dissipating substantial amounts of altitude”, “remaining over a selected spot”, and “useful during an emergency landing.” While these describe the maneuver’s purpose, the execution details can still feel a bit vague.

Specifically, the handbook mentions the following regarding the setup:

Airplane Flying Handbook 10-4

Although “gliding” is mentioned multiple times (e.g., “gliding turn” “gliding speed is established”), I don’t believe this implies the entire maneuver must be flown strictly at the best glide speed (Vg).

Since the text says “once the proper airspeed is attained, the pitch should be lowered and the airplane rolled…” after mentioning the initial glide setup, I interpret “gliding speed” as part of the initial entry procedure rather than a strict requirement to maintain that exact airspeed throughout the entire steep spiral.

How Steep is “Steep”?

How exactly do we define a “steep” turn? The Airplane Flying Handbook provides a very clear definition (thanks again to “SeoulCitizen” for pointing this out).

Airplane Flying Handbook 3-12

According to the AFH, “turns are divided into three classes: shallow, medium, and steep” where “Steep turns—result from a degree of bank of approximately 45° or more.” Therefore, for a maneuver to be called a Steep Spiral, it must involve a bank angle of at least approximately 45°.

So, What Are the Exact Numbers?

I’ve complained quite a bit, but that’s just because I truly believe the Steep Spiral is one of the trickiest maneuvers out there. At the end of the day, the goal is to find the “sweet spot” for bank angle and airspeed, while figuring out how to handle wind correction. I went through a lot of trial and error in X-Plane to find these numbers.

⚠️ Keep in mind, these aren’t absolute values—they will change depending on the situation.

Reasoning behind Airspeed: 90 KIAS (and why Vg might not be ideal)

While some suggest using Best Glide Speed (Vg), I found it a bit risky for this maneuver. In a PA-28-161, Vg is around 73 KIAS. However, at a 60° bank, your stall speed increases by about 41%. Vs1 for PA-28-161 is 51, and if you maintain a 60° bank while maintaining Vg (73), you’re gonna be only 1 knot above (51*1.41=72) the stall speed. That’s why I prefer 90 KIAS (within the Va range of 88-111) to Vg. And the reason why I didn’t choose 100KIAS is, 100 is too close to the maximum maneuvering speed 111, even though it depends on the weight of the aircraft. Therefore, I believe 90 KIAS is the sweet spot for a steep spiral.

Safety: It provides a much better stall margin, especially when you’re pulling steep banks.
Stability: The aircraft feels more stable and responsive to control inputs, even if you encounter sudden gusts.

Airplane Flying Handbook 5-9

Bank Angle Strategy: 45° as the Baseline

Through my practice, I found that 45° is a great baseline—but only if there’s no wind. To maintain a constant radius, you have to adjust based on your Ground Speed (GS):

Approaching Tailwind: Your GS increases. You need a steeper bank here, or your turn radius will balloon out, taking you away from your reference point.
Approaching Headwind: Your GS decreases. You need a shallower bank to prevent the circle from “pancaking” or getting too tight.

Downwind Entry - Wouldn’t Headwind be easier?

While a headwind entry might seem more “controlled” due to the slower initial ground speed (GS), it often leads to a common trap. I eventually realized that starting from the downwind (tailwind) leg is the most strategic way to stay within ACS limits.

The Problem with Headwind Entry: Starting with a headwind requires a shallow bank initially. However, as you turn toward the tailwind side, your GS increases rapidly. If the wind is strong, you may be forced to exceed a 60° bank just to maintain a constant radius—instantly busting the ACS limit
The Logic of Tailwind Entry: Entering downwind forces you to establish your steepest bank angle at the very beginning. By “setting the ceiling” (up to 60°) when your GS is at its peak, the rest of the maneuver becomes a matter of gradually shallowing out the bank as you turn into the wind. It eliminates the risk of needing “more bank than you have left” halfway through the turn.

The Simulation (X-Plane)

Since I can’t just go up and fly 50 times in the real world, I used X-Plane. Initially, I just wanted to see what the ground reference should look like from the cockpit, but I got a little obsessed… and here we are. In the video below, I’ll show you three scenarios:

Wind Calm: How a constant 45° bank and 90-95 KIAS creates a perfect circle.
Wind 180@20kts & No Correction: What happens to your circle when you hold a steady 45° bank without accounting for the wind.
Wind 180@20kts & With Correction: My experimental results on how to achieve that “constant radius” while staying within the 60° ACS limit.

Rule of Thumb (based on GS)

GS < 80: Use a 30° bank. (Don’t go much lower than this, or the radius gets too wide.)
GS = 90–95: Stick to the 45° baseline.
GS > 110: Increase to a 55° bank (But remember, never exceed 60°).

More GS, More Bank, More Back Pressure
Less GS, Less Bank, Less Back Pressure

Why Back Pressure Matters

Wait, why did I mention back pressure? It’s all about maintaining that target airspeed (90-95 KIAS) while your bank angle constantly changes.

When GS increases (Tailwind):

As you increase the bank to keep the radius constant, you lose the vertical component of lift. This causes the nose to drop, and your airspeed starts to bleed upward. To stay within the 90-95 KIAS range, you need to apply more back pressure to hold the pitch.

When GS decreases (Headwind):

As you shallow out the bank, the vertical lift increases. If you keep the same pitch, the nose will rise and your airspeed will drop. To maintain your target speed, you need to relax the elevator—less back pressure (or even a slight forward pressure)—to keep the nose down.

Track Log

It might not be perfect, but it gets the job done.

Track Log on Google Earth (Side View)

Track Log on Google Earth (Top View)

Commercial Operations: From Confusion to Clarity - Part 119 & 119.1(e)

Thu, 05 Feb 2026 00:00:00 +0000

Intro

The topic I underestimated the most was Commercial Operations.
I soon realized that concepts like Private vs. Common Carriage, Wet vs. Dry Leases, Holding Out, and the complex web of regulations—Part 91, 119, 119.1(e), 121, 125, and 135—are deeply interconnected and very confusing.
I’ve put a lot of effort into unraveling these tangled concepts to truly understand how they fit together.
In this post, I’m sharing my findings and a simplified Decision Roadmap to help fellow pilots navigate these ‘gray areas’ with clarity.

Disclaimer

⚠️ This content is for educational and informational purposes only. It does not constitute legal advice or an official FAA guideline. Always refer to the latest FAR/AIM and official regulations for actual flight operations. The author assumes no liability for errors or omissions in the content.

Opening Thoughts

There are many ways to make money in the aviation industry. You could earn a living as a pilot, or make a profit by leasing your aircraft to others. You might even own the plane and fly it yourself for business. Another option is providing a full private jet service, where you supply both the aircraft and the pilot while managing the plane for the client.
On the other hand, not all flights are for profit. You might fly for instruction, skydiving, or simply for fun. Some flights provide essential medical services to people in remote areas during emergencies.
With so many different types of operations, you can’t just let everyone fly however they want. Without clear rules (even though it’s not very clear), there would be no legal standards to follow when accidents or issues occur. It’s not just about punishment; it’s about establishing safety regulations by law.
Realistically, however, you cannot apply the same safety standards and regulations to someone flying alone for fun as you would to a private jet operator or a commercial airline carrying 300 paying passengers.
This is why aviation law is naturally complex and, like anything made by humans, imperfect.
Please see this writing as my own personal effort to make sense of these complicated regulations.

Case Table

‼️ The table below is the key takeaway from this post ‼️
(Click on the image for a larger view)

If the table below seems a bit confusing, I highly recommend reading through the Terms & Definitions and Key Takeaways first. At the end of this post, I will walk you through each case in the table step by step to make sure everything is clear.

Case Table

Terms & Definitions

Compensation: Anything of value received for acting as PIC (not limited to cash)
- Financial Gain: Direct payment (cash, salary).
- Flight Time: Building hours for free while someone else pays for the aircraft.
- Barter & Gifts: Trading services for goods (e.g., free dinner, repairs).
- Intangible Benefits: Business goodwill or professional reputation gain.
- If you are better off (financially or professionally) after the flight, the FAA considers it Compensation.
Hire: Air transport is the main business for profit, not incidental
- Pilot for Hire: Selling labor/skills for compensation.
- Aircraft for Hire: Using the aircraft as a revenue-generating vehicle.
  - Requires a 100-hour inspection (91.409b) in addition to the Annual.
  - An Operator must be identified as legally responsible for the flight.
  - Usually requires a Part 119 Certificate (Part 135/121) unless it falls under Part 119.1(e) exceptions.
Holding out: An expression of willingness to the general public to provide air transportation for compensation.
Private carriage: Carriage for hire which does not involve “holding out” is private carriage.
Common carriage: (1) A holding out of a willingness to (2) transport persons or property (3) from place to place (4) for compensation.
Operational control: The authority to initiate, conduct, and terminate a flight.
Operator: the person or entity who is legally responsible for the safe conduct of the flight and exercises operational control.
Dry lease: A leasing arrangement where only the aircraft is provided without a crew; the lessee has operational control and acts as the operator.
Wet lease: A leasing arrangement where both the aircraft and at least one crew member are provided; the lessor typically retains operational control and acts as the operator.
Air carrier certificate: A certificate required for operators conducting common carriage (e.g., Part 121 airlines or Part 135 on-demand air taxis).
Operating certificate: a certificate required for operators conducting private carriage for compensation or hire (e.g., Part 125 or Part 135 management companies).
14 CFR
- part 119: Regulation that determines who must obtain a certificate and which operating rules (Part 121, 125, or 135) apply.
- part 119.1.(e): List of commercial operations (such as student instruction, crop dusting, and banner towing) that are exempt from commercial certification and allowed to operate under Part 91.
- part 91: General operating and flight rules (basic rules for all aircraft). It covers non-commercial flights, corporate private operations, and the specialized operations listed in 119.1(e).
- part 121/135: Regulations for commercial operators conducting Common or Private Carriage for compensation or hire.
- part 125: Special regulations for the private operation of large aircraft (20+ seats or 6,000 lbs+ payload) that do not involve common carriage. (→ “you’re part 91 but too big, I want to manage you more strictly”)

AC 120-12A - Common Carrier

Key Takeaways

Purpose of the certificate
- Purpose of the certificate is to strictly manage the operator who carries the general public or others for compensation.
- Private operation is not a commercial activity (carriage). Since the aircraft is used for own business or personal purposes, it is sufficient to just follow Part 91 flight rules without the need for a separate certificate.
Things possible without a certificate (air carrier / operating):
- Pilot skill can be provided. Providing only pilot labor is ‘employment’, not an ‘air transportation service’. Operational control remains with the aircraft owner, not the pilot.
- Aircraft can be provided (dry lease). The lessee becomes the operator. Part (91/135/121/125) applies depends on how the lessee uses the aircraft.
- ↔ Providing both “pilot skill + aircraft together (wet lease)” → Certificate (air carrier / operating) is required.
Carriage vs non-carriage
- The key to determining whether it is carriage or not is the lease type (dry/wet), which means “who has operational control”.
- Dry lease: The lessee has control → non-carriage (Part 91 possible).
- Wet lease: The lessor/contractor has control → carriage (Part 135/125/121).
Private carriage vs Common carriage
- Key difference between private and common carriage is holding out.
- AC 120-12A states “(1) a holding out of a willingness to (2) transport persons or property (3) from place to place (4) for compensation.”
Common carriage always requires an air carrier certificate.
Part 125 is focused more on “safety management for large aircraft” rather than being a “commercial transportation business” itself.
In the event of an accident, legal responsibility lies with the person or entity that holds operational Control.

Case Table - Break Down

‼️ The table below is the key takeaway from this post ‼️
(Click on the image for a larger view)

Based on the Definitions, and Key Takeaways we’ve covered, let’s take another look at the table below.

The main premise is this: providing just the pilot’s skills is allowed, and providing just the aircraft is allowed. However, providing both together is not possible without a certificate (either an Air Carrier or Operating Certificate).

Case Table

Vary - 14 CFR 119.1(e)

There are various cases, such as flight instruction, banner towing, aerial photography, crop dusting, sightseeing, and parachute jumping.
For these operations, I have marked Lease Type and Operational Control as Depends.
This is because the scenarios vary greatly: an instructor might use their own plane or one owned by a flight school; a skydiving company might provide both the aircraft and the pilot; or a farm owner might use their own plane and simply hire a pilot for crop dusting.
Because of this wide variety, Part 119.1(e) does not specify a single standard for these cases.
In short, if an operation falls under these exemptions, it is not restricted by the usual regulations, regardless of whether there is holding out or if the flight is for compensation or hire.

Corporate Jet (Small / Large)

In both cases (Small and Large), the company must own the aircraft and maintain Operational Control by using a Dry Lease structure.
- A prime example is Mark Cuban, the owner of the Dallas Mavericks, who owns his own Boeing 757/767 and uses it for team operations.
The company can either hire its own crew directly or outsource the practical management to an Aircraft Management Company.
- In the latter case, the management company only provides services like supplying pilots, purchasing fuel, and handling maintenance.
The applicable regulations depend on the aircraft size:
- owning a Pilatus PC-12 falls under Part 91, while owning a Boeing 737 falls under Part 125.
- If the aircraft is large enough to be under Part 125, an Operating Certificate is required.
Two Critical Points to Remember
- No “Holding Out”: It is illegal for a company to provide flight services to the general public using its private jet when it’s not in use. To earn revenue from an idle aircraft, the owner typically dry leases the plane to a company like Executive Jet Management (EJM). EJM then provides that aircraft to clients via a wet lease and shares the profit. In this scenario, the company providing the wet lease (like EJM) must hold a Part 135 Air Carrier Certificate.
- Must be “Incidental to Business”: The primary purpose of the flight must be the business itself, with the aircraft serving merely as a means of transportation for that business. For example, if a friend of the company CEO uses the jet for a vacation, it is illegal. This is because the flight is no longer incidental to business; instead, the “place-to-place transportation” has become the primary purpose of the flight.

#GRAY AREA

This is the most controversial area and one that the FAA monitors very closely.
The key factor here is whether the operation qualifies as “Common Carriage” as defined in AC 120-12A.
If you are a pilot who owns an aircraft and provides transportation services via a wet lease for compensation, it can still fall under Part 91 as long as there is no holding out.
- This is possible if the customer finds you first or if the transportation stems from a very specific, pre-existing business relationship.
- A typical example would be: A CPL pilot with their own SR22 providing long-term travel services exclusively for 1–2 specific business partners under signed contracts.
- This is a case where the boundaries are not clearly defined, making it a “gray area” that is easily exploited.
Operating under Part 135 requires much stricter and more expensive standards for pilot training, maintenance intervals, and insurance compared to Part 91. Some operators try to bypass these costs by running a Part 91-style operation while generating revenue like a Part 135 carrier.
Regarding Private Carriage, AC 120-12A mentions that the FAA generally considers having 18 to 24 or more contracts as a sign that you have effectively opened your services to the public. On the other hand, it suggests that having up to 3 contracts is generally acceptable.
- So, what about having between 4 and 17 contracts?
- We have to accept that because laws are created by humans, they are inherently imperfect and some level of ambiguity is unavoidable.

AC 120-12A - Private Carrier

Aircraft Management Company

This case applies when an NBA team or a corporation wishes to operate a private jet without owning it, choosing instead to purchase transportation services from a company like EJM (Executive Jet Management).
Since the provider supplies both the crew and the aircraft as a package (Wet Lease), receives compensation, engages in holding out, and provides place-to-place transportation, it is classified as Common Carriage. This is still true even if tickets are not sold to the general public. (Reference: AC 120-12A)
Small Aircraft? → Part 135 applies.
Large Aircraft? → In this case, you should not assume it falls under Part 125 just because it is a large aircraft. The purpose of Part 125 is to enforce stricter safety management on large aircraft that would otherwise be operated under Part 91. In this scenario, a Part 135 Air Carrier Certificate is required, and the operation must comply with the specific regulations for large aircraft within Part 135.

Charter Company

An on-demand service (e.g., Tradewind Aviation) where anyone from the general public can book a seat for a weekend trip to Martha’s Vineyard.
These companies engage in holding out by advertising their services to the public and operating based on individual customer requests.

Airline

Large-scale carriers that operate on fixed routes and pre-determined schedules under Part 121.
They are the most prominent example of holding out to the general public, providing scheduled transportation services to anyone willing to purchase a ticket.

Gray Area Cases (Not Mentioned in the Table)

Case 1: A corporate jet pilot flying the CEO’s family to the Bahamas

This is not Part 91 operation because the flight is not incidental to business.
Since the flight’s purpose is personal rather than business-related, it should technically fall under Part 135 standards.

Case 2: If ‘L’ is the lessor, ‘P’ is the pilot, and ‘C’ is the client—can ‘L’ lease the plane to ‘C’ and also recommend ‘P’?

No. The moment the lessor recommends a pilot, the arrangement is viewed as a Wet Lease.
This brings it into the Part 135 category, and without an Operating Certificate, it becomes an “illegal charter.”

Case 3: ‘L’ leases the plane to ‘C’ without recommending a pilot, but ‘C’ already knows ‘P’ and hires them independently.

While the end result looks the same as the previous case, it can be operated under Part 91 because ‘L’ provided no information about ‘P’.
There must be absolutely no professional link or connection between the aircraft provider and the pilot provider.

Case 4: Can a company provide a business jet via a wet lease but let the client keep Operational Control?

No. It is a fundamental legal principle that the moment a Wet Lease agreement is made, Operational Control (the responsibility for flight safety) shifts to the service provider.
Therefore, the provider must hold a Part 135 (or 121) Operating Certificate.

Case 5: Are there cases of providing a wet lease under Part 91/125 (Private Carriage) while also “holding out”?

Legally, this cannot exist. However, companies like Executive Jet Management (EJM) appear to operate this way.
The reason they can is that they actually hold the necessary Part 135 certificates, allowing them to legally bridge that gap.

Post-Flight Analysis: Near Engine Failure (RPM Gauge Anomaly)

Thu, 05 Feb 2026 00:00:00 +0000

Intro

What would you do if your RPM gauge started fluctuating at 1,000 RPM during a full-power climb at night?

I recently faced this exact scenario on an IFR flight. Although I chose a precautionary landing over declaring an emergency, the experience revealed some critical gaps in my ADM. Here is a raw debrief of what happened during my night flight and what I learned.

About the Flight

Date: Feb 5th, 2026
Time: Night Operation (Sunset 17:30, Takeoff 17:58, Land 18:05)
Weather: VFR (Wind calm, Vis 10+, Sky clear, Temp -10℃, Altimeter 29.92)
Flight Plan: IFR Filed
CRAFT: 7B2 KEYNN MANCH KASH, 3000ft/5000ft 10minute, Bradley Approach 125.35, Squawk 5304
PIC: Me, ASEL 216.4, PIC 139.4, Night PIC 23.5, INST (real 1.9, hood 51.2), XC 111.4

Flight Detail (FlightAware)

⚠️ The Incident

Situation: Contacted Approach after departure, cleared to climb and maintain 5,000ft
RPM gauge anomaly: While climbing through 2,300’ (approx. 3NM Northeast of 7B2), I noticed an anomaly on the RPM gauge. Despite being at full throttle and mixture, the needle was bouncing erratically between 1,000 and 1,500 RPM.
Immediate Assessment: check fuel tanks, engine gauges, full mixture/throttle, fuel pump ON. No abnormal engine sounds, no smells, airspeed and altitude remained stable.

What Went Well (The Good)

Monitoring & Early Detection: Continuous scanning of engine gauges during the climb allowed for early identification of the erratic RPM.
Composure: I remained calm and avoided panicking.
Power Check: My safety pilot suggested a brief full-power burst while descending from 2,500’ to 1,100’ within a 1.5 NM distance at idle. This was an excellent move to verify the engine’s actual responsiveness.
Energy Management: Maintained a tight pattern after entry for a safe landing.
DECIDE Model Application:
- Note: Rather than consciously following the model, my thought process naturally flowed through these stages.
- Detect: Identified the RPM fluctuation at 2,300’ early in the climb.
- Estimate: Confirmed engine sound and flight parameters were normal, but decided the unstable gauge made it unsafe to continue the flight.
- Choose: Decided to return to the departure airport (7B2).
- Identify: Planned to cancel IFR with ATC, inform them of the situation, and initiate a turn.
- Do: Executed the plan, flew a tight base turn, and landed safely.
- Evaluate: Conducted this post-flight review as part of the final evaluation.

Flight Path Detail (GoogleEarth)

Areas for Improvement

I should have executed a “Direct-to 7B2” on the GPS immediately to get a bearing on the HSI. While I tried to identify the airport visually first, the lack of visual cues at night delayed my situational awareness. In an abnormal situation at night with high-workload, relying solely on eyes outside can be deceptive. Always use the “Direct-To” function as a primary source of orientation before attempting to acquire the field visually especially at night.

Takeaway: Utilize System-Based Orientation over Visual Search (especially at night)

2. Radio Communication

I was preoccupied with the thought of canceling my IFR flight plan. Because I was landing at a non-towered airport, I was worried that I might forget to cancel it later, which would unnecessarily trigger a Search and Rescue (SAR) mission. This concern, combined with the stress of the situation, made it difficult to find the right words for ATC. My thoughts became cluttered, and as I tried to speak too quickly, my radio calls became rushed and disorganized. Even when the controller asked, “Verify you are canceling IFR,” a simple “Affirmative” would have been enough. Instead, I gave a long-winded explanation that wasn’t necessary.

Better Approach: Keep it simple and direct. “Approach, 85NA, engine issues, turning direct to Northampton, cancel IFR.”
I didn’t need to over-explain. Focus on clear, concise communication.

Takeaway: Keep it brief when the workload is high.

3. Checklist Usage

I failed to perform a formal “Do-and-Verify” of the Engine Roughness or Engine Failure checklist. To be fair, since the engine sounded normal and my flight data was stable, I assumed the engine was fine and didn’t think I needed the checklist for what seemed like just a gauge glitch. Furthermore, being just 3NM from the runway at 2,400ft (well above the 1,100ft TPA), my mental bandwidth was entirely occupied with planning the pattern entry and landing. However, despite these factors, I should have at least verified the “Engine Roughness” checklist to confirm the engine’s health.

Takeaway: Always verify with the checklist, even if the issue seems like a sensor failure.

4. Post Flight

Post-flight Inspection I should have performed a more thorough visual inspection of the engine bay after landing to check for any mechanical causes.

Self Reflection

My Judgment: I assessed that a formal deviation or emergency declaration wasn’t necessary at the moment. I focused on canceling the IFR flight plan first before initiating the turn.
Q1: Was canceling IFR the best choice? What if the engine had actually failed right after I canceled the flight plan? Instead of being so worried about the IFR cancellation, wouldn’t it have been safer to simply say, “Declaring emergency, engine issue, turning direct 7B2”? By keeping the IFR or declaring an emergency, either way would have given me priority handling and reduced my workload by having ATC monitor my terrain clearance.
Q2: What if this happened at an unfamiliar airport? I was lucky that this happened at my home base where I know the terrain well. If I were over unfamiliar territory at night, canceling IFR would have been a much riskier move. Staying on the IFR plan would have ensured I had radar vectors and terrain clearance until the runway was in sight.

Final Thoughts

Through this real-world ADM (Aeronautical Decision-Making) experience, I was able to objectively identify the areas where I still need improvement.
While the outcome was safe, it highlighted the critical importance of utilizing all available resources—GPS, ATC, and checklists—during an abnormal situation, especially at night.

No More Confusion: Departure vs. Upwind Leg in the Traffic Pattern

Sat, 18 Oct 2025 00:00:00 +0000

Intro

The Confusion Ends: Find out how the new AIM update permanently resolves the debate between the Departure and Upwind Legs.

Source: [AIM] Explanation of Changes, [AIM][4-3-2] Airports with an Operating Control Tower

⚠️ This content is for educational and informational purposes only. It does not constitute legal advice or an official FAA guideline. Always refer to the latest FAR/AIM and official regulations for actual flight operations. The author assumes no liability for errors or omissions in the content.

TL;DR;

Effective: August 7, 2025
The Departure Leg is the segment flown from the start of the takeoff roll until the initial turn (either crosswind or a departure turn) is executed.
The Upwind Leg is the segment flown when the pilot does not turn crosswind after the initial departure, but instead continues straight ahead along the extended runway centerline.
Going forward, when Air Traffic Control (ATC) instructs you to “extend upwind,” you know the exact procedure: you simply continue flying straight ahead along the extended runway centerline.

Old Confusing Definition of Upwind and Departure Leg in AIM (Before Update)

I sourced this material from AC 90-66C, which appears not to reflect the AIM update of August 7, 2025.

(BEFORE UPDATE) Confusing Explanation of Departure vs Upwind in AIM

The term “Extend Upwind” caused significant confusion among pilots and CFIs before the AIM definition was clarified. When ATC used the term, they usually intended for the pilot to continue straight ahead along the extended runway centerline (an extended departure leg).

However, pilots familiar with older AIM definitions often misinterpreted “Upwind Leg” as flying parallel to the runway but offset and opposite the landing direction, outside the standard traffic pattern circuit.

While it is highly unlikely that any pilot actually flew the complete, incorrect Upwind Leg in response to an ATC instruction, this ambiguity undoubtedly created a moment of brief confusion and hesitation in the cockpit as the pilot tried to reconcile the ATC instruction with the manual’s definition. The subsequent AIM update successfully aligned the definition with the common operational practice.

AIM Updates (Aug 7th, 2025)

Detailed explanation about the updates are well written here [AIM] Explanation of Changes. What I’d like to talk about in this article is [AIM][4-3-2] Airports with an Operating Control Tower this.

AIM Updates (Aug 7th, 2025)

This change realigns the AIM definition and graphic depiction of upwind leg at towered airports with current ATC use and expectation. ATC usage of upwind leg is an extension of departure. The AIM’s current definition of upwind has led to confusion among pilots and controllers. The new proposed graphic depiction of upwind in FIG 4-3-1 as well as the definition in 4-3-2c aligns with common usage at towered airports.

What’s Updated? -> [4-3-2] Airports with an Operating Control Tower

FIG 4-3-1 and Definitions in 4-3-2c are the main updates about Departure and Upwind leg confusion.

AIM Updates (Aug 7th, 2025)

Departure: The flight path that begins after takeoff and continues straight ahead along the extended runway centerline. The departure climb continues until reaching a point at least 1/2 mile beyond the departure end of the runway and within 300 feet of the traffic pattern altitude.
Upwind leg: A flight path that begins after departure and continues straight ahead along the extended runway centerline. Upwind leg is an extension of departure and is used when issuing control instructions for separation, spacing, or sequencing.

Summary of Updates

The Departure Leg is the segment flown from the start of the takeoff roll until the initial turn (either crosswind or a departure turn) is executed.
The Upwind Leg is the segment flown when the pilot does not turn crosswind after the initial departure, but instead continues straight ahead along the extended runway centerline.
Going forward, when Air Traffic Control (ATC) instructs you to “extend upwind,” you know the exact procedure: you simply continue flying straight ahead along the extended runway centerline.

Instrument Rating Checkride Oral Cheat Sheet (Quick IR review)

Sat, 15 Feb 2025 00:00:00 +0000

Intro

There’s a lot to study for your IR checkride oral, and trying to review everything can be inefficient when you’re short on time.
So, I’ve summarized and simplified the essential knowledge into a very simple format.
This isn’t a detailed, in-depth explanation of each topic.
It’s meant for quick review when you want to rapidly go over everything you’ve studied, especially in the week leading up to your exam.

⚠️ This content is for educational and informational purposes only. It does not constitute legal advice or an official FAA guideline. Always refer to the latest FAR/AIM and official regulations for actual flight operations. The author assumes no liability for errors or omissions in the content.

Qualifications

requirements: AME (age/medical/english) TWEET (training-ground&flight/written/endorsement/experience/training-instrument)
privilege: PPL privilege + can fly *IR required
limit: pro rata share
*IR required: classA / SVFR sunset sunrise / PIC [weather<VFR / pass XC ≥ 50 or night]
proficiency vs currency: skilled & safe vs min legal req
unfamiliar: proficiency↓ → workload↑ → risk↑ → mitigate personal minimums & train & POH
SVFR: clearance to fly in control zone when weather below VFR [ceiling<1000, vis<3]
aero exp: 50 XC PIC, 40 inst (15hrs CFI, including 250nm filed XC - 3app, airway/routing)
FTD: BATD max 10hrs, AATD max 20hrs
PIC: flight review within 24 cal months [1hr-ground/1hr-flight] /w instructor, sub by prac test
- (within 24) 2025.09.16 flight → done at least 2023.09
carry pass as PIC: 3 TOL 90days, 1 after sunset to 1 before sunrise → full stop
IFR PIC: 66HITS, SIM (no instructor possible but proficiency↓), airplane (safety pilot)
- last 6 cal months (=exclude current month) → 9/16 IFR flight? 3/1~8/31 log acceptable
safety pilot: ppl, adequate vision, dual control
IPC: failed 66HITS + 6 cal month passed → IPC (by CFII, ACS p29, some with SIM)
- today 9/9 → no 6HITS in 3,4,5,6,7,8 → IFR currency expired
- grace period (6 months) → if 6HITS in 9,10,11,12,1,2? then IR current, otherwise IPC required March
IFR recency exemptions: PIC part 121/135
logging: soley ref inst, IAF/IF/FAF required (unless radar vectored to final: ATC or safety pilot), simulated IMC (airplane/SIM) → must MDA/DA, actual IMC → FAF pass okay (proficiency↓)
medical: mine [got my 1st class 2024.06, expires 2029.06.30], 40↓[12/48,12/48,60], 40↑[6/6/12,12/12,24]
BasicMed: regular physician for medical, bypass AME, alternative 3rd med, require [US driver’s, CMEC 48 months, online course 24 months, treatment, FAA med cert after 7/14/2006], limit [max 7 total, 12500lbs↓, 18000MSL↓, 250kts↓, in US]

Human Factors & ADM

IMSAFE, PAVE: FAA Personal Minimums Checklist
hypoxia: oxygen deficiency in body cells, 12000↑, hypoxic(altitude), hypemic(carbon monoxide poisoning/anemia), histotoxic(alcohol/drugs), stagnant(G-force), dizziness/headache
carbon monoxide poisoning: exhaust fumes, [dizziness/headache], solution [heat-off/vents-open/land ASAPoss]
hyperventilation: excessive breathing, [dizziness/headache], solution [talk/loud/paperbag]
body system
- vestibular: inner ear detects [motion/balance] → [pitch/roll/yaw]
- somatosensory: body nerves in [skin/muscles/joints]
- visual (eyes): rods (night & peripheral), cones (color, requires brighter light)
middle ear & sinus blockage: congestion blocks pressure equalization climb/descend, symptom[ear pain/facial pressure], solution[avoid flying/yawn/chew gums]
illusions: ICEFLAGS (FA=visual)
- inversion: climb→straight → tumbling backward
- coriolis: head, prolonged turn → trick inner ear → feels tilting/accelerating different direction
- elevator: strong updraft → feels nose-up
- false horizon: visual cues misinterpretation
- leans: slow bank → feels like level flight → actual level flight feels like banking opposite
- autokinesis: stationary light appears to move
- graveyard spiral: prolonged turns → feels like level flight → actual level flight feels like turning
- somatogravic: rapid [acceleration/deceleration] → feels like [nose-up/down]
oxygen (unpressurized cabin): above 12.5~14 (crew must use after 30min), above 14 (crew entire time), above 15 (each occupants provided)

Regulations & Documents

personal docs req: PRIM (Pilot cert/Radio license/ID-photo/Medical)
aircraft docs req: ARROW (A: Airworthiness Certificate)
maintenance inspections req: AVIATES (A: AD, S: Supplemental Type Certificate)
preflight: NWKRAFT (Notam/Weather/Known ATC Delay/Runway/Alternate/Fuel/TOL performance)
max airspeed: 250 [below 10000], 200 [under or VFR corridor class B / 2500↓ within 4NM class C D]
minimum equip req
- MEL → KOEL → 91.205 → 91.213(d)
- 91.205: ATOMATOFLAMES (VFR day), FLAPS(VFR night), GRABCARD(IFR)
- for hire over water (unless part 121): flotation device for each, at least 1 pyrotechnic signaling device
- above FL240: using VOR → DME/RNAV required
ATOMATOFLAMES: altimeter/tachometer/oil-pressure/manifold-pressure/airspeed/temperature-engine/oil-temperature/fuel-quantity/landing-gear-position-light/anti-collision/magnetic-direction/ELT/safety-belts
FLAPS: fuses or circuit-breaker/landing-light/anti-collision/position(navigation)/source of electricity
GRABCARD: generator or alternator/2way-radio/altimeter(sensitive)/ball(slip-skid)/clock/attitude-ind./rate-of-turn/directional-gyro(heading ind.)

Operating With Inoperative Items (91.213)

Weather Service & Product

flight category: LIFR,IFR,MVFR,VFR: vis[1,3,5], ceiling[500,1000,3000]
sources: aviation weather, 1800wxbrief(web&call), fltplan, EFB(ForeFlight), in-flight [FSS, FIS-B(ADS-B), NEXRAD, ATC]
ATIS: airport (wind, vis, sky, temp, dew, altimeter, NOTAMs), update hourly (55min)
AWOS: basic (wind, vis, altimeter, temp, dew, density alt)
ASOS: more advanced than AWOS+(precipitation type, intensity, runway condition)
METAR: routine weather report, airport, hourly(55-59min), valid current hour
SPECI: significant change (vis↓, thunderstorms, wind shifts), update with METAR
know how to read:
- SPECI KBAF 071007Z AUTO 36003KT 1/4SM R20/2200V3000FT FG VV002 19/18 A2980 RMK A02 T01890183
- KCCA 071015Z AUTO 00000KT 3SM VCTS RA SCT033 BKN080 OVC120 21/21 A2986 RMK A02 LTG DSNT ALQDS
- KBOS 251911Z 32006KT 5SM TS SCT055 BKN070CB OVC090 26/22 A2982 RMK A02 PK WND 26027/1855 RAE10 OCNL LTGICCC E TS E MOV E P0010 T02610217 $
PIREP: real-time by pilots, UA(routine), UUA(urgent, turbulence, icing)
- UA /OV LAX090015 /TM 1500 /FL050 /TP C172 /SK SCT025-TOP030 /WX FV04SM /TA 10 /TB LGT /IC NEG
- UUA /OV MYR180001/TM 1422/ FLDURD/TP CRJ7/WV +15 AT 400 FEET -20 AT 200 FEET
TAF: by meteorologists, forecast, 5SM radius around station, every 6hours (4 times a day - 00, 06, 12, 18), 24/30 hrs
- TAF AMD (amended, supersede previous TAF), TAF COR (corrected)
- TEMPO(temporary, lasting less than 1hr), FM (rapid change within 1hr), BECMG (gradual change up to 2hrs), PROB (probability, PROB30 → 30% chance)
know how to read:
- BECMG 3000/3001 VRB05KT 9999 NSW FEW050 SCT090 QNH2987INS TX23/2920Z TN11/3010Z
- 042025Z 0420/0523 1901520KT 9999 SCT060 BKN250 QNH2975INS WND 17009KT AFT 0502 TEMPO 0420/0501 21015G25KT 520005
winds aloft (FB): various altitudes, 4 times daily, (no wind 1500↓AGL, no temp 2500↓AGL), for [choosing alt/fuel plan/icing/freezing level/lapse rate/temperature inversion/turbulence], “7525-02”
AIRMET (WA): non-scheduled inflight advisory, hazardous light aircraft, valid 6hrs, S(mountain obscuration), T(srf wind≥30, turbulence, low-level wind shear), Z(icing, freezing level)
SIGMET (WS): non-convective severe, for all aircraft, not associated with thunderstorms, valid 4hrs (6 if hurricane), severe turbulence (CAT), severe icing, volcanic ash, dust/sand storms reducing vis to ≤ 3S
Convective SIGMET (WST):
- severe convective weather, hazardous to all aircraft, hourly at H+55, valid for 2hrs (severe or greater turbulence, severe icing, low-level wind shear)
- convective?: vertical movement of air caused by heating → thunderstorms & lightning
- issued for: (not for Alaska/Hawaii)
  - thunder-storm: areas ≥ 40% of 3000sq miles
  - severe thunder-storm: surface wind≥50kts, hail at surface ≥ 3/4 inch in diameter
  - embedded thunder-storm: obscured by cloud layers
  - squall line thunder-storm: at least [60 miles long & affecting at 40% of its length]
Convective Outlook (AC): forecasting tool, broad view of t-storm. expectation, available SPC, 8 day outlook (1,2,3,4-8), issuance [day1(5times), day2(2times), day3(1time)]
NEXRAD: ground-based radars, not real-time (5-20min delay), detects [t-storms, precipitation (heavy rain), wind speed, atmospheric motion]
surface analysis chart: snapshot of current weather, on the ground, every 3hrs, provides[H/L, fronts, isobars, weather symbols (rain/fog)]
prognostic chart: forecast of future weather, 6/12/24/48 hrs ahead, 4 times daily, provides[H/L, fronts, isobars, weather hazards (turb/icing/precipitation)]
CVA: ceiling & visiblity analysis, graphical weather, quick overview of ceiling & vis

Weather Theory

abbreviation for this section: t-storm(thunderstorm), vis(visibility), w.(wind), p.(pressure), turb(turbulence), cl.(cloud), ws(wind shear), alt(altitude)
atmosphere: [nitrogen78/oxygen21/argon0.9/water-vapor0-4]%
standard day: 15℃ (59℉), 29.92”Hg (1013.2hPa or mb)
heat exchange: sun uneven heating → warm(less dense)↑ & cold(denser)↓ → air movement
stable air: resists vertical motion, stratiform, smooth air, steady precipitation, fair-poor vis
unstable air: promotes vertical motion, towering(cumuliform), rough air, showery precipitation, t-storms., good vis
lapse rate: rate at which temp↓ as alt↑, standard 1000’↑ [2℃/1”Hg]↓, steeper(temp↓rapidly as alt↑) → unstable/convective act
temp inversion: temp↑ as alt↑, hot-day&cool-night→ ground cools → still hot above → warm air lid → trapping cooler air → vis↓(smog/haze),wind shear
wind shear: sudden change wind speed/direction in small area
- sudden drastic change in IAS, affect lift & control, low-level ws (less time to recover)
- mainly occurs: t-storms, frontal boundary (cold front), temperature inversion, CAT at high, microbursts
mountain wave: strong w. blow perpendicular to mountain, severe turb, lenticular/rotor cl.
factors affecting wind:
- pressure diff [diff↑→wind↑]
- coriolis force: earth’s rotation, deflect wind/air right Northern Hem., poles↑equator:0
- friction btwn air/surface: slows down wind→coriolis force↓→wind flow across isobars at slight angle toward low pressure (surface wind slower & turb. than winds aloft)
- gravity: vertical air movements (downbursts/microbursts)
isobar: connect points equal pressure, closer→pressure gradient↑→wind↑
high pressure: air moves[outward/downward/clockwise], typically clear&stable, sinking air warms up→preventing clouds forming
low pressure: air moves[inward/upward/counter-clockwise], generally cloudy&unstable, often rain/snow, rising air cools→moisture condense→[form clouds,icing risk]
trough: brown, elongated area of low p., air↑(can’t sink or spread)→cloud forms&precipitation→often bad weather
ridge: yellow, elongated area of high p., air↓→often good weather
turbulence: unsteady/irregular motion of air
- thermal turb: hot days→uneven heating→warm air↑→cumulus clouds & storms
- mechanical turb: wind blowing over [rough ground/mountains]→choppy air
- frontal turb: two air masses(cold front)→warm air↑→instability&bumps
- CAT: invisible in clear sky, often near jet stream (due to strong wind shear)
dew point: temperature at which air becomes saturated → no longer hold water vapor → condensation begins (water vapor → liquid)
- closer temp&dewpoint→humidity↑visible moisture↑(fog/clouds/dew/frost/rain)→ vis↓
- aircraft surface == dew point → frost
- temperature < dew point → icing
precipitation: any form of water that falls from the atmosphere (rain/drizzle/sleet/hail)
- sleet: snow(solid, ice crystals)+freezing rain(rapid structural icing)
- hail: ice pellets produced by strong updrafts in thunderstorms
fronts: boundaries between two air masses
- squall line? → ahead of a cold front
- cold front moves over mountainous? → icing
- frontal waves? → slowly moving cold fronts or stationary fronts
- low level wind shear? → warm front (temperature inversion)
cold front (blue): [cold/dense/fast-moving/20-30kts or faster] air forces warm air to rise rapidly → steep frontal surface, generally more intense (after:temperature↓&clr sky)
- hazards: rapid weather change(few hours), towering cumulous(nimbus), strong turbulence, gusty winds, heavy precip, squall line t-storms., hail, tornadoes
warm front (red): [warm/less dense/slow-moving/10-15kts] air glides up over cooler air mass → gradual frontal slope, generally less intense, produce [wide area of weather/stratiform/ceiling↓/vis↓/rain/drizzle&fog]
- hazards: freezing rain → icing (warm rain falls into cold air layer and freeze)
stationary front (red&blue): two air masses balanced, neither is advancing, can last for days, mixed cold&warm fronts, hazards[low-intensity precip, poor vis, low cloud]
occluded front (purple): fast-moving cold front catches up slower-moving warm front → lifting warm air mass entirely off the ground, mixed cold&warm fronts
- hazards: strong winds/turbulence/embedded thunderstorms with thick cloud layers]
- more severe when warm front occlusion (embedded thunderstorms)
clouds: moist air cooled to its dew point → water vapor condenses into tiny liquid
- caused by lifting: convective(air heated&rise), orographic(air rise by mountain), frontal
- hazards: icing, turb(cumuliform clouds), vis↓, thunderstorms
cloud types: cumulus(piled), stratus(in layers), cirrus(high-level,20000↑), nimbus (rain-bearing), alto(middle-level,5000-20000)
- lenticularus: lens-shaped, formed over mountains in strong winds
- virga - contains strong downdrafts
- rotor clouds
thunderstorm: unstable(steep)lapse rate, sufficient moisture(small temp-dewpoint spread), lifting action(surface heat, orographic, frontal)
thunderstorm stages: cumulus[cloud develop/strong updrafts], mature[most intense/up&down-drafts/rainfall begins/severe turb/wind shear/lighting/hail], dissipating[weakens/mostly downdrafts/rainfall decrease/often anvil top]
thunderstorm caution: keep 20NM distance (hail/rain can be thrown up to 20NM)
microburst: [undetectable/small/strong]downdraft→sudden/powerful winds near ground
- losing altitude 6000ft/min, dangerous WS(especially takeoff/landing)
- wind(150mph=131kts), short-lived, lasting 5-15 min, less than 2.5 miles wide
fog (PAIRUS): cloud near surface(50’), air cools to its dew point & moisture added
- precipitation: rain→moisture evaporates→humidity↑→air saturated, warm rain through cooler air[warm front/temperature inversion]
- advection: warm/moist air moves over cooler surface (coastal areas), opposite of steam fog, forms quickly, cover large areas
- ice: extremely cold (below -25°F), Arctic regions
- radiation: calm/clear night, ground cools air above, dissipate with sunrise
- upslope: wind pushes moist/stable air to upsloping terrain (mountain obscuration)
- steam: cold/dry air moves over warm water
fog vs mist: fog(vis<5/8mile), mist(5/8≤vis<7) is often dissipating form of fog
frost: surface below freezing, water vapor condenses onto that surface
- effects: even thin layer→significantly disrupt airflow→lift↓drag↑→stall speed↑
- hazards: dangerous especially during takeoff, block [pitot tubes, static port]
- removal: [anti-icing/de-icing] fluid, wipe off, melt in [heated hanger, sun]
freezing rain: rain→ice (it was rain above but freezes at current altitude -> rain that starts to freeze)
- temperature inversion: above warm layer → cold → snow → [snow→rain] at warm layer → [rain→ice] at cold surface → ice pellets at surface means [freezing rain/supercooled water] at higher altitude
- rain from air 0℃↑ → into air 0℃↓
- rain freezes on impact
- temp could be 0℃↑ at higher alt.
- freezing drizzle→warmer air above
wet snow: ice→rain (it was snow above but melts at current altitude -> snow that starts to melt)
- wet snow at your alt.→ temp>freezing → freezing level above

Icing

PA28: defroster, carb heat, pitot heat
intensity: trace, light, moderate(accumulation 1~3inches/hour), severe
low-pressure areas: rising air → cool down → visible moisture↑ → icing risk↑
performance degradation:
- 1/2 inch ice → lift↓ by 50%
- icing→disrupts airflow(lift↓thrust↓drag↑weight↑)→AoA↑→stall speed↑
- approach speed↑, landing distance↑
- sandpaper-like icing on leading edge and upper surface → lift↓by30%&drag↑by40%
mitigate: icing&rolling→use aileron↓rudder↑, tailplane stall→use caution app&land, disengage auto-pilot VS mode, deicing, anti-icing
- hand fly, find cloud base/top, leave visible moisture (climb/descend/turn), warmer temperature, lower humidity
- in some cases, reaching -10℃ could be an option, since visible moisture is less likely to be present
types: instrument, induction, structural
- instrument icing: forms on instruments & sensors → inaccurate readings → pitot-heat
- induction icing: forms in engine’s air intake system → airflow↓ → disrupts air/fuel mixture → engine performance↓ → engine failure (carb icing)
  - carburetor icing: forms when [temperatures (-7~21℃, 70℉) / relative humidity above 80%], due to steep temperature drop in carburetor venturi → carb heat
- structural icing: forms when visible moisture contacts below freezing aircraft surface, forms on exterior surface (wings/tail/props) → change airfoil shape → risk↑
  - clear: large droplet spreads. [smooth/clear/hard/dense]→difficult [detect/remove]
  - rime: small droplets freeze instantly. [milky(rough&white) color, brittle texture] → easier to spot, forms on thinner parts (wing edges)
  - mixed: when [snow/rain] coexists(unstable/mixed clouds), severe performance loss
+structural icing: “most likely”→freezing rain (“least” likely→high clouds), mostly form on tail in rain when temperature few degree above freezing, opposite of ICTS
SLD (Supercooled Large droplets)
- liquid water droplets that remain in a liquid state even at temp below freezing.
- occur aloft even without precipitation at surface.
- visual indication: droplets that splash on impact at temperatures below 5℃
freezing level: lowest altitude temperature 0°C, must get accurate freezing level before IFR, sources [AWC/winds aloft forecast (FB)/PIREP/weather briefing]
FIKI: [frost/ice/snow] on airplane→not allowed, but deicing or anti-icing equip to protect[wings/windshield/controls/instrument]? → allowed (use caution)
icing on airfoils: shape change→weight↑lift↓(less noticeable at low AoA)→stall speed↑
- small ice→localized stall→roll/spin, likely form first on tailplane, flaps already extended?(never retract)→retract?→stall speed↑
roll upset: can be caused by localized stall, try [AoA↓/airspeed↑/extend flaps/wings level]
tailplane: tailplane creates tail-down force→nose-up moment→counteracts nose-down moment created by lift, better ice collector than wings
tailplane icing (ICTS): Ice Contaminated Tailplane Stall, mostly during approach/landing
- tailplane icing→tail-down force↓→nose-down↑ ← don’t [deploy flaps or speed↑]
  - if flaps or speed↑→lift↑→even more nose-down
- symptoms: elevator[vibration↑effectiveness↓heavier] & uncommanded nose-down
- recovery: retract flaps immediately, and then speed↑ to counteract flap retraction, slowly control nose-down pitch, no-flaps approach
plan&predict (CAFFU): Cloud layers, Air temperature & pressure (more likely in low-pressure areas, cool temperatures), Fronts movement, Freezing level, Use weather briefing (METAR/TAF/AIRMET/SIGMET)
anti-icing/deicing: anti-icing(prevention), deicing(removal)
- for airfoil: inflatable deicing boots, thermal anti-ice leading edge, weeping wings
- for windshield: alcohol anti-ice, electric heating anti-ice, defroster
- for propeller: alcohol anti-ice, electric heating anti-ice, deicing boots
- others: pitot heat, carb heat

Instrument & Attitude Flying

basic skills: CIA, errors: fixation/omission/emphasis
set power & attitude, then monitor performance
- (first) control: power [tach/manifold p.], attitude (attitude ind.)
- (second) performance: pitch [altimeter/ASI/VSI], bank (heading ind/turn cord./mag.comp]

primary & supporting

pitch: attitude ind., altimeter, airspeed, VSI
- bank: attitude ind., heading ind., mag. compass, turn cord.
- power: airspeed, tachometer, manifold pressure
- primary instruments: not moving / not changing

table

Maneuve r	Pitch	Bank	Powe r
Straight & Level	Altimeter	Heading	Airspeed
Climbs / Descents (Airspeed)	Airspeed	Heading	VSI
Climbs / Descents (Vertical Speed)	VSI	Heading	Airspeed
Turns	Altimeter	Turn Coordinator	Airspeed
Transition to Climb	Attitude	Heading	VSI/Airspeed
Transition to Turn	Altimeter	Attitude	Airspeed
ILS Approach	Glide Slope	Localizer	Airspeed

gyroscopic principles
- rigidity in space: spinning gyro remains fixed in its plane of rotation, providing stability
- precession: force is applied to gyro, resulting force occurs 90° ahead in the direction of rotation
gyroscopic instruments
- att ind: bank/pitch, rigidity in space, vacuum-driven or elec, correct in 5 start engine, errors[acceleration?/deceleration?/roll-out?]
- head ind: heading, rigidity in space, vacuum (calibrate w mag.com) or elec
- turn ind: rate-of-turn & rate-of-roll, precession, turn coordinator (both), turn-and-slip ind (rate-of-turn only)
pitot-static instruments: pitot tube (dynamic p), static port (ambient static p), pitot mast
- altimeter: measure altitude above specific ref (sea level, Kollsman window), 75ft airport elev, High to Low Look out Below
  - how: altitude↑→pressure↓→wafer expands→mechanical linkage→indicate
- VSI: shows rate-of-climb in fpm, 6-9sec delay, rate trend immediate
  - how: diaphragm direct static source, chamber receives static p via calibrated leak, climb/descend→diaphragm p change instantly, chamber change slowly→pressure diff→mechanical linkage→shows rate of climb
- ASI: measures diff between impact(ram) air p (pitot tube) and ambient p (static port)
  - how: dynamic p (airspeed)=impact p - static p, diaphragm receives ram air p from pitot tube [faster→expand], air p↓ as alt↑ → ASI indicate slower → to correct → apply ambient p from static port → shows dynamic p as airspeed
types of altitude: indicated, true (actual/MSL), absolute (AGL), pressure, density
- PA: corrected for non-standard p. (FL180↑→29.92), formula
- DA: PA corrected for non-standard temp, formula
- [pressure↓/humidity↑/temperature↑] → DA↑ → less dense air → performance↓
- DA ↑ → [takeoff & landing roll ↑ / rate of climb ↓ / same IAS but TAS ↑ on landing]
types of speed: IAS, CAS (IAS corrected for instrument & position errors), TAS (CAS corrected for pressure & non-standard temperature), GS (TAS corrected for wind)
markings: white-flaps (Vso~Vfe), green-normal (Vs1~Vno), yellow-caution, red-Vne
Vspeeds(PA28): Vs0(44),Vs1(51),Vne(160),Vno(126),Va(88-111),Vfe(103),Vy(79),Vx(63),Vg(73,LDmax),Vb(87,Vs1*1.7),landingfinal(63),crosswind(17)
pitot-static blockage
- static port: airspeed (alt↑→speed↓, correct only at blocked), altimeter(freeze), VSI(0)
- using alternate static source → venturi effect → lower pressure
  - airspeed↑, altimeter↑, VSI (momentarily climb)
- pitot tube: use pitot-heat
  - ram air inlet (x) & drain hole (o) → 0 (zero)
  - ram air inlet (x) & drain hole (x) → like altimeter
instrument taxi check: ASI 0, VSI 0, altimeter ±75ft, heading correct, att (bank ±°5 within 5 minutes of engine start, if vacuum), turn cord (turn → ball goes to opposite), compass (swings freely, full of fluid)
magnetic compass err VODM: variation(diff true N mag N, east least west best), oscillation(swinging needle turb or maneuv), deviation(aircraft mag field), magnetic dip (earth’s magnetic field pulling needle down, north affinity, acc decel error ANDS, turning err UNOS)
electronic flight inst: AHRS, ADC, FD, FMS, EFIS

IFR rules

IFR flight plan: FSS[radio/phone/RCO/person], ARTCC, online[1800/fltplan/EFB], 30min prior dep (4hrs before if FL230↑), cancel[towered:auto, non-to:pilot→ATC/FSS, anytime out A or no IMC], form [7233-4 INT, 7233-1 FAA]
- your filed plan will be shown on ATC’s side for 2 hours
min fuel: dest, alt, 45min cruise
alternate required: 1123 (11ETA, ceiling 2000, vis 3SM)
alternate airport weather minima: 600/2 precision, 800/2 non-precision, no IAP?→ceiling & vis desc MEA, app & landing VFR
GPS considerations: non-WAAS (1 GPS app), no baro-VNAV WAAS (plan LNAV both), baro-VNAV WAAS (plan LNAV/VNAV or RNP0.3 both)
IFR cruising alt: →odd, ←even, MC, above FL290, RVSM
IFR takeoff minimums: part91[priv/GA/train] none, part121/135 (1-2eng:1SM, eng>2:1/2SM), even though 91[vis↓&ceiling↓→ODP→if 200f/nm not avail→VCOA]
IFR min alt: not allowed ↓min-altiutde, if none → mountain 2000/4, non-mountain 1000/4
required reports: MARVELOUS VFR C500 == fix/points: MCFOH, change: AEA, safety: US EU (CFO, E: non-radar)
position reports: IF TPA fix/point/remarks [ID, flight plan type, time, position, altitude, next reporting fix (ETA & name), next succeeding point (name), remarks]
other keywords: cruise clearance, block altitudes, minimum fuel (non emergency)

IFR Flying Procedures

DP: TO→ENR transition, [DER35’/400’turn/200FPNM], course guidance [10NM straight, 5NM turn], ODP/SID(workload↓, graphic), not required but encouraged [night/MVMC/IMC]
Diverse DP: IAP but no DP, requires airport no obs 200FPNM up to min IFR alt, turn 400’, DVA
VCOA: designed to avoid 3SM from DER, visual climbing turn up to published alt, alternative for >200fpnm, advise ATC
clearance: after 30min CVT ATC, EDCT 5min, how (clearance/ground/pop-up/PDC/CPDLC), hold for release (traffic mgmt, class D only 1 IFR, hold until “released for departure”), “expect 3000 10 min after”→clearance limit for lost comm
VFR-on-top: by pilot request, only FL180↓(no class A), at above MEA, comply IFR regulations, VFR cruising alt, VFR cloud clr & vis req, report reaching VFR-on-top
STAR: ENR→APPR transition, [flow/sequencing] for busy, at least a textual required, “No STARs” remarks, RNAV STARs RNAV1 performance
holding: for [missed/delay/traffic/weather/emergency], clearance items?, reduce speed 3min before, 5T, min of [3°sec/30°bank/25°FDS], speed limit [~6~14/200,230,265], inbound [14000↓1min, 14000↑1.5min], leave [EFC/ETA if lost comm/report]
lost comm: 7600, “in the blind”, Highest MEA (minimum IFR alt., expected, assigned), route orderly AVEF (Assigned, Vectored, Expected, Filed), VFR ASAPrac, light-gun
leaving clearance limit
- if c-limit is approach begin fix: start descend & approach as close as possible to EFC (if no EFC → ETA)
- if c-limit not approach begin fix: leave c-limit at EFC
  - if no EFC: upon arrival over the c-limit, proceed to a fix where approach begins and commence descent as close to ETA
PT: course reversal, descent from IAF, 10NM, max 200kts, NoPT, SHARPTT
- NoPT when SHARPTT: straight-in/holding-in-lieu-of/DME Arc/radar vectors/NoPT/time approach/teardrop course reversal

VOR
- full deflection 10° (5 dots, 2° deviation for dot), verify morse ID
- check: [VOT±4/ground±4/airborne±6/dual-check 4 between two], every 30 days, check FROM 0 / TO 180, sensitivity (at 5th dot within 10°~12°)
- sign: DEPS (Date / bearing Error / Place / Signature)
- limit: cone of confusion (1 mile per 10,000ft), reverse sensing, require line-of-sight
DME: auto tune with (VOR/LOC), slant range error (right above 6076ft shows 1NM), negligible 1NM per every 1000ft (you 5000ft? → negligible when 5NM away)
NDB: low-mid freq band, older form → replacing, how: [sends signal all direction → ADF (automatic direction finder) points needle to NDB station]
ILS: instrument landing system, localizer, glide slope, marker beacons,
ILS failure: outside FAF (→switch LOC), inside FAF(→Missed)
Localizer: opposite end of rwy, lateral guide, width (3°-6°), threshold 700ft (350ft each from center), usually 5° total width (2.5° each side → 4x sensitive than VOR), coverage[10NM-35°/18NM-10°/4500ft]
glide slope: vertical guide, auto tune /w LOC, interprets 90Hz/150Hz signal (90Hz>150Hz → above), width (1.4°, 0.7 for up/down deach), range (10NM), slope (3°)

marker beacons: provides range information

Marker Beacon	Color	Audio Pattern	Distance from RWY	Height (AGL)
Outer Marker (OM)	Blue	— (slow)	4~7miles (21000~37000ft)	about 1400ft
Middle Marker (MM)	Amber	-.-. (middle)	0.5~0.8miles (2600~4200ft)	about 200~250ft
Inner Marker (IM)	White	….(fast)	near threshold (within 300~500ft)	below 100ft

GPS keywords
- update every 28 days
- GNSS: all satellite system world-wide, including GPS (US GNSS - dep of Defense)
- GPS: type of GNSS, operate by US dep of Defense
- SBAS: ground stations → accuracy 10x↑, [WAAS(US)/EGNOS(EU)/KASS(KOR)]
- WAAS: type of SBAS, FAA run, [error margin 3 meters / position accuracy 95%↑]
- GBAS: installed near airport, GLS can replace ILS, accuracy↑ than WAAS but coverage↓)
- RAIM: detects satellite error → gives warning, min 5 functioning required, WAAS GPS no need RAIM but built for backup
- TSO-C[129,196]: non-WAAS GPS, no SBAS correction, alternate require non-GPS
- PBN (set of standard), RNP (type or RNAV, RNAV with alert, RAIM, WAAS)
- RNP0.3 (APPR), RNAV1 (DP, STAR), RNAV2 (ENR)
- approved GPS: G1000, GNS 430/530, GTN750 (↔ non approved:ForeFlight)
RNAV (Area Navigation): fly any path using its own equip, without overfly ground-based facilities, types[GNSS,VOR/DME,DME/DME], no GPS RNAV possible
RNAV NavSpecs: lateral navigation accuracy, RNAV1 [DPs/STARs]: less 1NM err 95%, RNAV2 (enroute,T/Q-routes): less 2NM err 95%, RNAV10 (for oceanic)
how GPS works
- 5 satellites at any location→each satellites sends time-stamped signal→receiver measures travel time of signal→calculate distance to each satellite
- 3 satellites → position (lat/long), 4 satellites → position & altitude
- RAIM: GPS receiver monitors satellite signal integrity, min 5 (or 4+ altimeter input (baro-aided RAIM)), fault exclusion → min 6 (or 5 + alt input)
PBN: set of navigation equip standards (particular NavSpecs), not dependent on single tech, procedure don’t need to be changed/renamed just because of new nav hardware
RNP: type of PBN, “statement” of nav equip and service performance
- RNAV: no alerting
- RNP: type of RNAV + [monitoring/alerting] function (RAIM or WAAS)
- RNP0.3 approach: nav. sys. must maintain accuracy of 0.3NM or better from runway centerline during final approach segment → accuracy<standard?→alert
- RNP approach minima and equipment:
  - GLS DA minima → require GBAS
  - LP MDA / LPV DA minima → require RNP achieved by WAAS.
  - LNAV / VNAV DA → achieved by VNAV-approved WAAS, or BARO-VNAV systems.
  - LNAV MDA → achieved by a basic, unaugmented IFR-approved GPS.
- RNP Navigation Performance
  - Final Approach: RNP 0.3 (0.3 NM accuracy 95% of flight time)
  - Terminal & Departure: RNP 1.0 (1 NM accuracy 95% of the flight time)
  - Enroute: RNP 2.0 (2 NM accuracy 95% of the flight time)

Localizer

Glide Slope

Marker Beacon

Approach

stabilized approach: landing config, on profile, airspeed±10, descent rate 500~700 (no more than 1000), optimal RPM
chart reading: TDZE(highest in first 3000’), THRE(threshold elev.), MSA(guarantees 1000’ obs. clear. within 25NM radius, no sig coverage), TCH (threshold crossing height)
- signs[T/A/Ana]: T[non-standard TO mins / DP], A[non-standard IFR alternate min], Ana[alternate minimums not authorized=can’t be used as alternate airport]
- signs[snowflake]: Cold Temperature Airport X mark → altitude correction (AGL), AIM 7-3 correction table (how far below due to cold temperature induced error)
identify FAF: precision (light-bolt), non-precision (maltese cross)
approach category
- Based on final approach speed (1.3 times stall speed in landing configuration at MGLW (maximum gross landing weight))
- A ≤ 90, B (91-120), C (121-140), D (141-165), E > 165
descend below MDA/DA (91.175): normal descent rate, not less than visibility requirement, visual reference requirement
visual reference requirements: runway environment in-sight
- [threshold, runway, touchdown zone] markings or lights, REIL, VASI, PAPI
- ALS : red terminating bars (ASLF-1) or red side row bars (ALSF-2) → descend below 100ft above TDZE
missed approach
- identify [precision: DA / non-precision: MAP]
- execute when: “MDA→MAP or DH/DA” with insufficient visual ref, unsafe app, ATC
- immediately go-missed when: CDI deflects 3/4-scale↑ (horizontal/vertical), RAIM lost, when below MDA/DA (visual contact lost, vis<minimum, not in normal pos.)
approach clearances: when can you descend to next approach segment? → cleared for app. & established on segment of published app.
VDP: non-precision, ‘V’ symbol on profile, no below MDA prior to reaching VDP
- no VDP? → maintain MDA until 91.175 is met → descend
- VDP on chart? then maintain MDA to VDP (even if 91.175 is met)
- at VDP? → 91.175 meet? then descend, otherwise go missed
- formula: (MDA in AGL) / 300 → NM, (MDA in AGL) / 10 → sec
VDA: glide path from FAF to TCH (for non-precision), typically 3°, advisory only
IAP (Instrument Approach Procedures)
- precision: ILS, MLS, PAR, GLS, TLS → lateral & vertical guidance to DA
- non-precision: VOR, LOC, RNAV/RNP to LNAV or LP Minima, LDA, SDF, ASR, NDB → lateral only to MDA, step-down
  - NDB, VOR, LOC: may use IFR-certified GPS as primary source until the FAF
- APV: prevision-like, to DA, with vertical guidance but doesn’t meet precision standard
  - LDA with Glide Slope, LPV, LNAV/VNAV
other types of approach: circling/visual/contact/radar-vectors/parallel/GLS
- circling: course alignment↔rwy center exceeds 30°, approach name not include rwy (VOR/DME-B), remain 1.3NM (for category A) radius of all runways (B1.5, C1.7, D2.3, E4.5), visual ref lost while circling? (climbing turn to landing rwy → continue turn until established on missed course)
- visual: pilot or ATC initiate (pilot can reject), vis≥3SM, ceiling≥1000 (IFR under VMC), must have [airport or traffic to follow] in-sight, pilot responsible visual separation
- contact: similar to visual but SVFR, only init by pilot (no ATC), airport with IAP (ground vis≥1sm, remain Coc), obs. clr. pilot’s responsibility
- radar vectors to final: at least 2NM outside FAF, until cleared [no turn to final / maintain last assigned altitude]
- parallel ILS: provides 1 1/2 miles radar separation between aircraft
- GLS: only 3 airports, KEWR, KIAH, Boeing private
LPV vs LNAV/VNAV:
- LPV: requires WAAS, GPS based, no temperature error
- LNAV/VNAV: non-WAAS ok, GPS + baro-VNAV based → temperature error

Approach Chart

RVR

Approach Lighting System

Airspace & IFR Low Chart

special user airspace: MCPRAWN
- MOA: military training zones, permission NOT required, but extreme caution (advised to contact the controlling agency)
- Controlled firing: NOT ON CHART (means no one knows where the controlled firing space is), potential hazards (firing will be stopped if an aircraft is detected)
- Prohibited: [P-**], security reasons, NOT ALLOWED
- Restricted: [R-**], hazardous activities, PERMISSION REQUIRED if active
- Alerting: [A-**], high traffic volumes (ex. pilot training). exercise caution.
- Warning: [W-**], potential hazards, 3NM off the U.S. coast.
- NSA (national security area): temporarily prohibited, not to enter voluntarily, ADIZ (2-way radio, transponder, file IF or DVFR)
- (+) TFR: prohibited without authorization. check NOTAM.
- (+) SFRA (Special Flight Rules Area): Grand Canyon, Washington DC, Hudson River
minimum altitude for IFR
- no applicable minimum altitude? → mountainous (2000↑ highest obs., 4NM horizontal), others (1000↑ highest obs., 4NM horizontal)
- DA(DH): precision, above rwy threshold
- MDA(MDH): non-precision, above wy threshold, visual references
- MCA: route & direction, must cross higher than MCA, flying to higher MEA, X flag
- MTA: obstacle clearance (vertical/lateral) turns over fixes
- MRA: lowest alt for nav signal. R flag
- MEA: nav signal reception & obstacle clearance (along airway), MEA GAP
- МОСА: obstacle clearance (could be lower than MEA), guarantees VOR signal within 22NM(25SM) of station, * sign
- MVA: could be lower than MOCA, assigned by ATC.
- OROCA: obstacle clearance within 1° grid square, no signal guaranteed (VFR MEF)
- MAA: max authorized alt
- MSA: guarantees 1000ft obstacle clearance within 25NM, no sig coverage
airport: blue/green (IAP), brown (no-IAP), show only if hard-surface rwy 3000ft↑
airways: V(victor, black, VOR), T(tango, blue, GPS)
reporting points: VHF fix [on VOR radial, triangle, required report when not in radar contact], GPS fix [without VOR possible, RNAV navigation waypoint, T-Routes, Q-routes]
distance: plain number(leg), rounded(cumulative), square(total), COP(change over point)
off airways navigation: VOR only & below 18000ft ? → max distance between NAVAIDs = 80NM

W/B

forward: CG toward nose (stable)
- ↑stable(↓maneuverable), stall↑, TOL roll↑, cruise effi↓
- returns to level flight easily, harder to raise the nose, need↑elevator force
aft: CG toward tail (maneuverable)
- ↑maneuverable(↓stable), stall↓, TOL roll↓, cruise effi↑fuel↑
- less stable, more likely to pitch up, less elevator force is needed

스프링 카프카 Batch Consumer - 의도치 않은 리스너 호출

Sun, 07 Jun 2020 00:00:00 +0000

개요

스프링 카프카 Batch Consumer 를 사용하는데, 의도하지 않은 @KafkaListener 호출이 발생했다.
스프링 카프카 소스를 까본 내용을 정리해보았다.

TL;DR

spring kafka batch consumer 를 사용할때 누적 메시지 사이즈나 레코드 개수를 기준으로 가져오는 것이 아닌, 일정한 시간간격을 가지고 읽어들이고 싶은 경우에
@KafkaListener 메서드의 호출은, 카프카 클러스터를 구성하는 브로커 개수만큼(최대) 발생할 수 있다.
백그라운드에서 무한루프를 돌면서 polling 을 하고 있는데, 노드별로 비동기로 fetch 요청을 보내기 때문이다.
spring kafka 2.3 버전이후부터 제공되는 ContainerProperties 의 idleBetweenPolls 값으로 해결할 수 있다.
KafkaMessageListenerContainer 내부 콜 시퀀스 다이어그램

KafkaMessageListenerContainer funcation call sequence

아래부터는 파악하는 과정을 적어 보았다. (길어요 ㅠㅠ)

사용버전

java 11
spring boot 2.2.6.RELEASE
spring kafka 2.3.7.RELEASE
apache kafka client 2.3.1

배경

hive 로 적재하는 consumer group 하나가 있고, 같은 topic 에 붙어서 통계수치를 집계하는 다른 consumer group 을 추가해야할 일이 생겼다.

10초 간격으로 메시지들을 가져와서 group_no (각 메시지들을 그룹핑 할 수 있는 기준 값) 를 기준으로 집계하여 통계DB 를 업데이트하는 작업이었다.

하고자 했던 것

10초에 1회 @KafkaListener 메서드가 호출되도록 설정한다.
받아온 메시지들을 각각 group_no 를 기준으로 grouping 한다.
같은 group_no 로 들어온 메시지들이 몇개인지 DB 에 업데이트를 한다.

비교적 간단한 작업이었다. 근데 kafka 는 처음이라 좀 오래 걸렸다. (아직 쪼렙이라 다 처음이다 ^__^)

하고자 했던 것을 하기위해

consumer 관련 프로퍼티 설정

spring.kafka.consumer.max-poll-records=6000
spring.kafka.consumer.fetch-min-size=1MB
spring.kafka.consumer.fetch-max-wait=10s

key	default	description
max.poll.records	500개	10초에 한번 가져오도록 구성할 것이므로 충분히 큰 값으로 지정 –> 6000개로 변경
fetch.min.bytes	1byte	consume 할 메시지가 최소 1byte 라도 있으면 fetch 하는 것이 디폴트 –> 1MB 채워지기 전까지는 fetch 하지 않도록 변경
fetch.max.wait.ms	500ms	fetch.min.bytes 가 채워지지 않았다면 최대 500ms 동안 block 하는 것이 디폴트 –> 10초로 변경

1MB 가 채워지거나, 6000개 레코드가 채워지지 않으면 10초 동안 기다려라

code configuration

AbstractKafkaListenerContainerFactory 의 batchListener 설정을 true 로
ContainerProperties.AckMode.BATCH 사용
리스너에서 MyLogType 에 바로 매핑시킬 수 있도록 MyLogType 은 org.apache.kafka.common.serialization.Deserializer 를 구현

@Bean
public ConcurrentKafkaListenerContainerFactory<String, MyLogType> kafkaListenerContainerFactory(
    ConsumerFactory<String, MyLogType> consumerFactory
) {
    var factory = new ConcurrentKafkaListenerContainerFactory<String, MyLogType>();
    factory.setConsumerFactory(consumerFactory); // deserializer 를 구현한 consumer factory
    factory.setBatchListener(true);
    factory.setBatchErrorHandler(new SeekToCurrentBatchErrorHandler());

    var containerProperties = factory.getContainerProperties();
    containerProperties.setAckMode(ContainerProperties.AckMode.BATCH);

    return factory;
}

Listener

여러개 레코드들을 ConsumerRecords 에 담아서 돌려주면, value 만 뽑아내서 적당히 필터링하고, group_no 별로 카운트한뒤에, 집계된 수치만큼 DB 에 업데이트 하면 됨!

@KafkaListener(topics = "${spring.kafka.template.default-topic}")
public Integer onMessage(ConsumerRecords<String, MyLogType> consumerRecords) {
    StreamSupport.stream(consumerRecords.spliterator(), false)
                 .map(ConsumerRecord::value)
                 .filter(Objects::nonNull)
                 .filter(MyLogType::isCountable)
                 .collect(groupingBy(MyLogType::getGroupNo, counting()))
                 .forEach(repository::updateCount);
    log.info("{}_consumed:{}", rand.nextInt(10), consumerRecords.count());
    return consumerRecords.count();
}

10초에 한번씩 listener 가 호출되어 배치처럼 돌겠지?

잘되려나? - 내로잘

일단 deserialize exception 발생하는건 잠시 무시하고, kafka-producer-perf-test 를 이용해서 10초에 한번씩 호출되는지 확인해본다.

kafka-producer-perf-test.sh --topic log-topic-local --num-records 15000 --record-size 100  --throughput 500 --producer-props bootstrap.servers=localhost:9092

–> 1 record 에 100byte 짜리 메시지를 1초에 500개씩 총 15000개 보내라

kafka-producer-perf-test 는 30초동안 실행됨
1초에 500개씩 produce, 1초당 생산되는 데이터는 500 * 100 = 50000byte = 500KB
10초 동안 보내도
- 500KB * 10초 = 5000KB 로 fetch-min-size 인 1MB 가 안되고,
- 500개/s * 10초 = 5000개 로 max-poll-records 인 6000 이 안됨
즉, 10초에 한번씩 5000개 언저리의 메시지를 fetch 해올 것으로 예상
리스너 메서드는 10초에 한번씩 1회 호출되며, 5000개 언저리의 카운트를 출력할 것으로 예상

결과

kafka-producer-perf-test 결과

첫 호출건과 마지막 호출건은 5000개 가 다 채워지지 않을 수 있다. 약간 밀리기는 하지만 어쩔수 없고, 의도했던 10초에 한번씩 Listener 메서드가 호출되어 배치처럼 동작하는 것을 확인할 수 있다.

개발용 카프카 붙여서해보자

kafka-producer-perf-test 결과

얼레??? 10초 간격으로 호출되기는 했지만 Listener 메서드가 3번씩 호출된다.

뭐지? 추측

잘됐던 테스트는 로컬에 있는 카프카를 사용했다. 클러스터를 구성하지 않은 1대의 브로커만 있는 카프카였고, 개발용 카프카는 3대의 노드로 구성된 카프카 클러스터이다. 노드 개수와 리스너 호출수 사이에 상관관계가 있는 것 같다!

그냥 넘어갈까?

가정이 맞다면 7대로 구성된 운영환경 카프카 클러스터에서는 10초마다 7번씩 리스너 호출이 발생할 수 있고, consumer 는 1대가 아니라 여러대를 둘 것이기 때문에, 실제로 DB 업데이트 쿼리가 호출되는 횟수는 10초마다 node수 * consumer수 만큼 호출될것이다.

현재는 producer 에서 던지는 메시지가 round-robin 으로 브로커에 전달된다. producer 에서 key 를 줘서 던지면 같은 key 를 가지는 메시지는 같은 파티션으로 가기 때문에, 같은 group_no 가 여러개의 파티션으로 분산되는 지금보다 DB관점에서는 부하가 덜해지겠지만 완전한 해결방법은 아니다.

또한, group_no 마다 들어오는 메시지수가 일정하지 않고, 어떤 것은 엄청 많고 어떤것은 거의 없고 그렇다. 그래서 특정 partition 으로 메시지가 쏠릴수 있다.

문제가 된다.

왜이러지? 확인

먼저 @KafkaListener 를 호출하는 곳을 찾아야한다.

1. KafkaMessageListenerContainer.pollAndInvoke()

KafkaMessageListenerContainer 로 가면 run() 메서드가 있는데, 여기에서 무한루프 while 문이 실행되어 설정값에 설정한 대로 주기적으로 poll 해오는 곳이다. while 문 내에서 실행되는 pollAndInvoke() 안에서 중요한 모든 일들이 일어난다고 봐도 된다. (아래)

KafkaMessageListenerContainer.run()

(아래) pollAndInvoke() 메서드 내부를 들여다 보면, doPoll() 메서드로 records 를 가져와서 invokeListener(records) 를 통해서 넘겨주면 @KafkaListener 가 호출된다. 이부분이 무한루프 안에서 연쇄적으로 호출되어서 리스너 호출이 브로커 개수만큼 일어나는 것 같다.

KafkaMessageListenerContainer.pollAndInvoke()

invokeListener() 는 구동시점에 @KafkaListener 로 등록된 메서드를 호출하는 것 외에 딱히 하는건 없으니, doPoll() 안에서 무슨일이 벌어지는지 확인할 필요가 있다.

2. KafkaMessageListenerContainer.doPoll()

subBatchPerPartition 설정은 디폴트가 false 이므로 else 로 가게 되어, KafkaConsumer 의 poll() 을 호출한다. (poll timeout 은 별도 설정하지 않으면 ConsumerProperties.DEFAULT_POLL_TIMEOUT 인 5000ms 가 적용된다)

KafkaMessageListenerContainer.doPoll()

3. KafkaConsumer.poll()

이 안에서는 poll timeout 으로 지정한 시간만큼 루프를 돌면서 pollForFetches(timer) 를 호출한다.
(등록한 인터셉터로 records 를 넘기는 것도 볼 수 있다)

KafkaConsumer.poll()

4. KafkaConsumer.pollForFetches(timer) - 핵심

리스너가 왜 노드 개수만큼 호출되는지에 대한 원인을 찾아볼 수 있는 함수이다. 이 메서드가 하는 일은 동기적으로 생각하면 간단하다. fetch 요청을 보내고, fetch 된 데이터가 있으면 반환하는 게 전부다.

KafkaConsumer.pollForFetches(timer)

그런데 비동기로 구성되어 있어서 좀 헷갈린다. 비동기적으로 동작하기 위해서 내부적으로 2개의 큐를 이용한다. ConcurrentLinkedQueue 타입의 completedFetches 와 ConcurrentMap 타입의 unsent 이다.

completedFetches 는 fetch 가 완료된 데이터를 가지는 큐이고, unsent 는 fetch 요청을 담는 큐이다. 큐를 사용해서 비동기로 fetch 요청을 보내고, 받아온 데이터를 반환하는 방식은 아래와 같다.

호출부	설명
fetcher.fetchedRecords()	completedFetches 큐에 레코드가 있으면 반환한다. 어디선가 이 큐에 데이터를 계속 채우고, 여기서는 데이터가 있으면 설정한 개수만큼 가져와서 리턴하기만 한다.
fetcher.sendFetches()	fetch 요청을 노드별로 unsent 큐에 담는다. 이 메서드에는 RequestFuture 타입을 반환하는데, 이 Future 의 onSuccess 콜백 메서드에서 fetch 가 완료된 레코드들을 completedFetches 큐에 넣는다.
client.poll()	ConsumerNetworkClient.poll() 메서드 내부에서, unsent 큐에 담긴 fetch 요청을 실제로 네트워크를 태워서 보낸다.

(코드가 순차적으로 실행이 되기는 하지만, 무한루프 내에서 계속 호출되기 때문에 어떤 큐에 언제 데이터가 들어가고, 큐에 데이터가 있을 경우 어떤 동작을 하는지 큐를 중심으로 코드의 흐름을 파악해야한다.)

중요한 부분

unsent 큐에 fetch 요청을 담을때에 노드별로 담고, 실제로 fetch 요청을 보낼때에도 노드별로 요청을 보낸다는 것이다.

노드가 3개라고 치면, 3개의 요청이 unsent 큐에 담기고, 3개의 요청을 보내고, completedFetches 큐에 3개 노드에서 fetch 해 온 레코드들이 채워질때마다 return 을 하게되어 총 3번의 return 을 하게 된다. return 하면 doPoll() 을 호출했던 곳으로 쭉쭉쭉 리턴하게 되는데, 다음에는 invokeListener(records) 메서드 호출이 기다리고 있고, 여기서 @KafkaListener 메서드 호출이 총 3번 발생한 것이다.

해결방법

spring kafka 2.3 이상 버전이라면 ContainerProperties 에 idleBetweenPolls 값을 주어서 해결할 수 있다.

ContainerProperties.idleBetweenPolls

run() 메서드 무한루프 내에서 실행되는 pollAndInvoke() 메서드는 doPoll() 을 호출하기 전에 idleBetweenPollIfNecessary() 라는 함수를 먼저 호출한다.

pollAndInvoke()

idleBetweenPollIfNecessary() 는 이렇게 생겼다.

idleBetweenPollIfNecessary()

idleBetweenPolls 값이 0보다 크면 설정한 값만큼 스레드를 sleep 하여 루프의 진행을 멈추도록 한다. 이 메서드는 doPoll() 메서드 이전에 호출이 되기 때문에 completedFetches 큐에 데이터가 채워질때마다 리턴하는 것을 block 함으로써, fetch 시간동안 기다려서 노드별로 fetch 해온 데이터를 completedFetches 큐에 모두 쌓은다음, idleBetweenPolls 시간이 종료되면 한번에 return 하게 된다.

주의할 점은

idleBetweenPolls = Math.min(
    idleBetweenPolls, 
    this.maxPollInterval - (System.currentTimeMillis() - this.lastPoll) - 5000
)

코드에 의해 항상 내가 설정한 idleBetweenPolls 값대로 먹히는게 아니다. max.poll.interval 은 기본값이 30000ms 인데 25초보다 작은 경우에만 의도한대로 동작하고, 25초보다 크게 설정할 경우 max.poll.interval 도 수정해주어야 한다.

Call Sequence Diagram

지금까지 설명한 과정을 시퀀스 다이어그램으로 표현하면 아래와 같다.

KafkaMessageListenerContainer funcation call sequence

지금까지 과정을 다시한번 돌아볼겸 시퀀스 다이어그램 기준으로 다시 설명해보면

fetch 요청을 보낼때 (비동기)
- 직접 발송하지 않고 unsent queue 에 담기만 한다.
  - ConcurrentMap<Node, ConcurrentLinkedQueue> unsent
- 응답을 받으면 callback 리스너에서 completedFetches 에 응답결과를 추가
  - ConcurrentLinkedQueue completedFetches
실제 fetch 요청 전송
- ConsumerNetworkClient.poll() 내부에서 trySend() 호출시 node 별로 요청을 전송
그래서 원인은
- pollAndInvoke() 를 호출하는 while 문은 앱 구동중에 무한루프를 돌고 있음
- 이때 fetch 요청은 설정값대로 1MB 나 6000 레코드가 채워지기 전까지 10초를 기다림
- 그 와중에도 pollAndInvoke() 호출이 있는 루프는 계속 돌고있음
- fetch-max-wait 이 지나서 fetch 가 끝나면, 콜백리스너에서 completedFetches 에 각 노드별에서 돌려 받은 레코드를 파티션별로 add
- 노드가 7개라면, 7개의 요청을 보냈을 것이고, 최대 7번 콜백리스너가 호출될 수 있음
- 이 와중에도 루프는 계속 돌고 있는데, 돌다가 fetcher.fetchRecords() 결과로 records 가 있는 것을 보고 바로 반환을 하고,
  - (fetchRecords() 에서 compeletedFetches 큐에서 꺼내옴)
- pollAndInvoke() 로 돌아와서 다음 코드를 진행하는데, records 가 있으므로 invoke() 메서드를 호출하게 되고, 결국 노드 갯수만큼 호출함

스프링 - 생성자 주입을 사용해야 하는 이유, 필드인젝션이 좋지 않은 이유

Thu, 29 Aug 2019 00:00:00 +0000

개요

Dependency Injection (의존관계 주입) 이란
- Setter Based Injection (수정자를 통한 주입)
- Constructor based Injection (생성자를 통한 주입)
스프링에서 사용할 수 있는 DI 방법 세가지
생성자 주입을 이용한 순환참조 방지
생성자 주입이 테스트 코드 작성하기 좋은 이유

서론

의존관계 주입을 받을때는 아무생각없이 당연하게 @Autowired 를 사용한 필드주입 방식을 사용해왔다. 그런데 어느날 갑자기(?) 인텔리제이에서 경고메시지를 보여준다는 것을 보게 되었다. 항상 경고는 표시되고 있었겠지만 무시하다가 갑자기 궁금해졌다. 필드인젝션을 사용하고 있는 @Autowired 에 하이라이트 표시가 되면서 나오는 경고메시지는

Field injection is not recommended … Always use constructor based dependency injection in your beans

왜~~~~~~~~~~~~~~~???? 심지어 Always 라네

Dependency Injection (의존관계 주입)

이유를 알기 위해서는 DI 에 대한 이해가 필요하다. DI 는 스프링에서만 사용되는 용어가 아니라 객체지향 프로그래밍에서는 어디에서나 통용되는 개념이다.

강한 결합

객체 내부에서 다른 객체를 생성하는 것은 강한 결합도를 가지는 구조이다. A 클래스 내부에서 B 라는 객체를 직접 생성하고 있다면, B 객체를 C 객체로 바꾸고 싶은 경우에 A 클래스도 수정해야 하는 방식이기 때문에 강한 결합이다.

느슨한 결합

객체를 주입 받는다는 것은 외부에서 생성된 객체를 인터페이스를 통해서 넘겨받는 것이다. 이렇게 하면 결합도를 낮출 수 있고, 런타임시에 의존관계가 결정되기 때문에 유연한 구조를 가진다.

SOLID 원칙에서 O 에 해당하는 Open Closed Principle 을 지키기 위해서 디자인 패턴 중 전략패턴을 사용하게 되는데, 생성자 주입을 사용하게 되면 전략패턴을 사용하게 된다.

Setter Based Injection (수정자를 통한 주입)

의존관계 주입에는 크게 생성자 주입, 수정자 주입 두가지 방법이 있다.

코드를 한번 보자. 클래스나 인터페이스 이름만 Controller, Service, ServiceImpl 로 지정했지 스프링과는 상관이 없는 순수 자바로만 짜여진 코드이다.

먼저 수정자를 이용한 의존관계 주입을 보자.

public class Controller {
    private Service service;

    public void setService(Service service) {
        this.service = service;
    }

    public void callService() {
        service.doSomething();
    }
}

public interface Service {
    void doSomething();
}

public class ServiceImpl implements Service {
    @Override
    public void doSomething() {
        System.out.println("ServiceImpl is doing something");
    }
}

public class Main {
    public static void main(String[] args) {
        Controller controller = new Controller();

        // 어떤 구현체이든, 구현체가 어떤방법으로 구현되든 Service 인터페이스를 구현하기만 하면 된다.
        controller.setService(new ServiceImpl1());
        controller.setService(new ServiceImpl2());

        controller.setService(new Service() {
            @Override
            public void doSomething() {
                System.out.println("Anonymous class is doing something");
            }
        });

        controller.setService(
          () -> System.out.println("Lambda implementation is doing something")
        );

        // 어떻게든 구현체를 주입하고 호출하면 된다.
        controller.callService();
    }
}

(참고) 익명클래스나 람다로 구현할 수 있었던 것은 Service 인터페이스가 함수형 인터페이스이기 때문이다.

Controller 클래스의 callService() 메소드는 Service 타입의 객체에 의존하고 있다.
Service 는 인터페이스이고, 인터페이스는 인스턴스화 할 수 없으므로 인터페이스의 구현체가 필요하다.
Service 인터페이스를 구현하기만 했다면 어떤 타입의 객체라도 Controller 에서 사용할 수 있는데 (다형성) Controller 는 이 구현체의 내부 동작을 아무 것도 알지 못하고 알 필요도 없다.
main 함수에서 Controller 클래스를 사용하는 것을 보면, 수정자 메소드인 setService() 에 Service 인터페이스의 구현체만 넘겨주면 된다.

어떤 구현체이든, 구현체가 어떤방법으로 구현되든, Service 인터페이스를 구현하기만 하면 된다.

신박하다?

수정자 주입으로 의존관계 주입은 런타임시에 할 수 있도록 낮은 결합도를 가지게 구현되었다. 하지만 문제는 수정자를 통해서 Service 의 구현체를 주입해주지 않아도 Controller 객체는 생성가능하다. Controller 객체가 생성가능하다는 것은 내부에 있는 callService() 메소드도 호출 가능하다는 것인데, callService() 메소드는 service.doSomething() 을 호출하고 있으므로

NullPointerException 이 발생한다.

주입이 필요한 객체가 주입이 되지 않아도 얼마든지 객체를 생성할 수 있다는 것이 문제다.

이 문제를 해결 할 수 있는 방법이 생성자 주입이다.

Constructor based Injection (생성자를 통한 주입)

Controller 에 setter 를 없애고, 생성자를 이용해서 주입한다.

public class Controller {
    private Service service;

    public Controller(Service service) {
        this.service = service;
    }

    public void callService() {
        service.doSomething();
    }
}

이렇게 생성자 주입을 해주면 사용하는 쪽은 아래와 같이 바뀐다.

public class Main {
    public static void main(String[] args) {

        // Controller controller = new Controller(); // 컴파일 에러

        Controller controller1 = new Controller(new ServiceImpl());
        Controller controller2 = new Controller(
            () -> System.out.println("Lambda implementation is doing something")
        );
        Controller controller3 = new Controller(new Service() {
            @Override
            public void doSomething() {
                System.out.println("Anonymous class is doing something");
            }
        });

        controller1.callService();
        controller2.callService();
        controller3.callService();
    }
}

이를 통해 두가지 이득과 한가지 보너스 이득이 생긴다.

null 을 주입하지 않는 한 NullPointerException 은 발생하지 않는다.
의존관계 주입을 하지 않은 경우에는 Controller 객체를 생성할 수 없다. 즉, 의존관계에 대한 내용을 외부로 노출시킴으로써 컴파일 타임에 오류를 잡아낼 수 있다.

보너스 이득은 final 을 사용할 수 있다는 것이다. final 로 선언된 레퍼런스타입 변수는 반드시 선언과 함께 초기화가 되어야 하므로 setter 주입시에는 의존관계 주입을 받을 필드에 final 을 선언할 수 없다.

public class Controller {
    private final Service service; // final 추가

    public Controller(Service service) {
        this.service = service;
    }

    public void callService() {
        service.doSomething();
    }
}

final 의 장점은 누군가가 Controller 내부에서 service 객체를 바꿔치기 할 수 없다는 점이다.

스프링에서 필드주입은 수정자를 통한 주입과 유사한 방식으로 이루어진다. 이제 슬슬 생성자 주입의 장점이 보이기 시작한다.

스프링에서의 DI 방법 세가지

스프링에서는 수정자 주입, 생성자 주입과 더불어 필드 주입이란걸 할 수 있다. 필드 주입은 수정자를 통한 주입과 유사한 방식으로 이루어지기 때문에, 수정자를 통한 주입의 단점은 Field Injection 을 사용할 때의 단점을 그대로 가진다.

더불어, 수정자 주입은 스프링 컨테이너가 아닌 외부에서 수정자를 호출해서 주입할 수 있는 방법이라도 열려있지만, 필드주입은 스프링 컨테이너 말고는 외부에서 주입할 수 있는 방법이 없다.

아래는 각 DI 방법에 대한 간단한 예제다. 뒤에서도 쓰기 위해서 예제를 Student, Course 관련된 내용으로 변경했다.

Field Injection

@Service
public class StudentServiceImpl implements StudentService {

    @Autowired
    private CourseService courseService;

    @Override
    public void studentMethod() {
        courseService.courseMethod();
    }

}

Setter based Injection

@Service
public class StudentServiceImpl implements StudentService {

    private CourseService courseService;

    @Autowired
    public void setCourseService(CourseService courseService) {
        this.courseService = courseService;
    }

    @Override
    public void studentMethod() {
        courseService.courseMethod();
    }
}

Constructor based Injection

@Service
public class StudentServiceImpl implements StudentService {

    private final CourseService courseService;

    @Autowired
    public StudentServiceImpl(CourseService courseService) {
        this.courseService = courseService;
    }

    @Override
    public void studentMethod() {
        courseService.courseMethod();
    }
}

인텔리제이에서 보여주는 경고메시지는 위 두 예제 중 아래에 있는 Constructor based Injection 을 사용하라는 것이다.

지금까지 살펴본 생성자 주입의 장점은

NullPointerException 을 방지할 수 있다.
주입받을 필드를 final 로 선언 가능하다.

정도인데 또 다른 장점을 소개하고자 한다. 이는 스프링에서만 유용한 방법인 것 같다.

생성자 주입을 이용한 순환참조 방지

개발하다보면 여러 서비스들 간에 의존관계가 생기게 되는 경우가 있다. 이 예제에서는 CourseService 에서 StudentService 에 의존하고, StudentService 가 CourseService 에 의존하는 경우를 볼 것이다.

Field Injection 의 경우

public interface CourseService {
    void courseMethod();
}

@Service
public class CourseServiceImpl implements CourseService {

    @Autowired
    private StudentService studentService;

    @Override
    public void courseMethod() {
        studentService.studentMethod();
    }
}

public interface StudentService {
    void studentMethod();
}

@Service
public class StudentServiceImpl implements StudentService {

    @Autowired
    private CourseService courseService;

    @Override
    public void studentMethod() {
        courseService.courseMethod();
    }
}

이 상황은 StudentServiceImple 의 studentMethod() 는 CourseServiceImpl 의 courseMethod() 를 호출하고, CourseServiceImpl 의 courseMethod() 는 StudentServiceImple 의 studentMethod() 를 호출하고 있는 상황이다. 서로서로 주거니 받거니 호출을 반복하면서 끊임없이 호출하다가 결국 StackOverflowError 를 발생시키고 죽는다.

2019-08-28 00:14:56.042 ERROR 46104 --- [nio-8080-exec-1] o.a.c.c.C.[.[.[/].[dispatcherServlet]    : Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception [Handler dispatch failed; nested exception is java.lang.StackOverflowError] with root cause


java.lang.StackOverflowError: null
    at com.yaboong.alterbridge.tmp.CourseServiceImpl.courseMethod(CourseServiceImpl.java:26) ~[classes/:na]
    at com.yaboong.alterbridge.tmp.StudentServiceImpl.studentMethod(StudentServiceImpl.java:25) ~[classes/:na]
    at com.yaboong.alterbridge.tmp.CourseServiceImpl.courseMethod(CourseServiceImpl.java:26) ~[classes/:na]
    at com.yaboong.alterbridge.tmp.StudentServiceImpl.studentMethod(StudentServiceImpl.java:25) ~[classes/:na]
    at com.yaboong.alterbridge.tmp.CourseServiceImpl.courseMethod(CourseServiceImpl.java:26) ~[classes/:na]
…
…
…

이게 순환참조의 문제인데, 실제 코드가 호출이 되기 전까지는 아무것도 알지 못한다. 스프링 애플리케이션 구동도 너무나 잘된다. 여기서 궁금했던게 하나 있다.

왜 빈 생성이 잘 되는거지…?

수정자 주입이나 필드 주입시에 스프링 ApplicationContext 를 통해서 현재 로딩된 빈 목록을 출력하면 사이클 호출 로직을 가진 두개의 빈이 모두 떠있는 것을 확인할 수 있었다. 아니 사이클 호출을 하고 있는데 빈이 어떻게 생성될 수 있는거지? 생성은 안하고 빈 목록만 가지고 있다가 lazy 로딩하는 방식인건가? 근데 따로 lazy init 옵션을 주지 않으면 lazy 로딩은 적용 되지 않는다던데…?

여기저기 물어보니 한분이 명쾌한 답변을 주셨는데 ‘아 멍청이’ 하는 생각이 들었다. (혹시 보고 계신다면 다시한번 감사드립니다 ㅋ ㅋ) 객체생성시점에서 순환참조가 일어나는 것과 객체생성 후 비즈니스 로직상에서 순환참조가 일어나는 것은 완전히 다른 이야기인데, 하나로 묶어서 생각하고 있었기 때문에 이런 이상한 질문에 빠졌던 것이다.

필드 주입이나, 수정자 주입은 객체 생성시점에는 순환참조가 일어나는지 아닌지 발견할 수 있는 방법이 없다.

Constructor based Injection 의 경우

@Service
public class CourseServiceImpl implements CourseService {

    private final StudentService studentService;

    @Autowired
    public CourseServiceImpl(StudentService studentService) {
        this.studentService = studentService;
    }

    @Override
    public void courseMethod() {
        studentService.studentMethod();
    }
}

@Service
public class StudentServiceImpl implements StudentService {

    private final CourseService courseService;

    @Autowired
    public StudentServiceImpl(CourseService courseService) {
        this.courseService = courseService;
    }

    @Override
    public void studentMethod() {
        courseService.courseMethod();
    }
}

이 경우에도 애플리케이션이 구동이 잘 될까? 실행해보면 아래와 같은 로그가 찍히면서 앱 구동이 실패한다.

***************************
APPLICATION FAILED TO START
***************************

Description:

The dependencies of some of the beans in the application context form a cycle:

┌─────┐
|  courseServiceImpl defined in file [/Users/yaboong/.../CourseServiceImpl.class]
↑     ↓
|  studentServiceImpl defined in file [/Users/yaboong/.../StudentServiceImpl.class]
└─────┘

빈 생성시 아래와 같은 로직이 수행되면서 어떤 시점에 스프링이 그것을 캐치해서 순환참조라고 알려주는 것 같다.

new CourseServiceImpl(new StudentServiceImpl(new CourseServiceImpl(new ...)))

이처럼 생성자 주입을 사용하면 객체 간 순환참조를 하고 있는 경우에 스프링 애플리케이션이 구동되지 않는다.

컨테이너가 빈을 생성하는 시점에서 객체생성에 사이클관계가 생기기 때문이다!

수정자 주입을 사용하면 아주 잘 구동되고 순환참조를 하고 있는 부분에 대한 호출이 이루어질 경우 StackOverflowError 를 뱉기 때문에, 오류를 뱉을 수 밖에 없는 로직을 품고 애플리케이션이 구동되는 것이다.

마지막으로, 생성자 주입을 사용하면 단위테스트 작성하기가 좋아진다.

테스트 코드 작성하기 좋다

아직 테스트 코드를 열심히 짜보거나 하지는 않았지만, 요즘 테스트 코드의 중요성을 깨닫고 공부를 하고 있는 중이다. (참 일찍도 깨달았다 미련한 것)

CourserServiceImpl 이 가진 메소드들에 대해서 단위테스트를 수행하고 싶은 경우, field injection 을 사용해서 작성된 클래스라면 단위테스트시 의존관계를 가지는 객체를 생성해서 주입할 수가 없다. 할 수 있는 방법이 없다! 스프링의 IoC 컨테이너가 다 생성해서 주입해 주는 방식이고 외부로 노출되어 있는 것이 하나도 없기 때문이다. 그래서 의존관계를 가지고 있는 메소드의 단위테스트를 작성하면 (courseMethod() 같은) NullPointerException 이 발생한다.

하지만, constructor based injection 을 사용해 작성된 클래스라면 CourseServiceImpl 객체를 생성할 때 원하는 구현체를 넘겨주면 되고, 구현체를 넘겨주지 않은 경우에는 객체생성 자체가 불가능하기 때문에 테스트하기도 편하다.

요약

생성자 주입방식은 아래와 같은 장점을 가진다

의존관계 설정이 되지 않으면 객체생성 불가 -> 컴파일 타임에 인지 가능, NPE 방지
의존성 주입이 필요한 필드를 final 로 선언가능 -> Immutable
(스프링에서) 순환참조 감지가능 -> 순환참조시 앱구동 실패
테스트 코드 작성 용이

필드 인젝션은 아래와 같은 장점을 가진다

편하다는 것 말고는 없다

주저리

생성자 주입 방식의 장점으로… 주입받는 객체가 많아지는 경우 생성자가 길어지기 때문에 위기감을 느껴서 리팩토링을 하게 된다… SRP(Single Responsibility Principle) 이 깨진것을 파악할 수 있다.. 와 같은 이야기를 하는 곳도 있는데.. 뭔가.. 손꼽히는 장점이라고 하기에는 좀.. 우기는 것 같은 느낌이 있어서 그냥 내가 다른 자료들 찾아보면서 장점이라고 생각되는 것들 위주로 정리해봤다.

마무리

이제 생성자 주입을 써야할 이유가 생겼다 ~~~

참고한 자료

자바 제네릭 이해하기 Part 1

Sat, 19 Jan 2019 00:00:00 +0000

개요

제네릭이란?
제네릭을 사용하는 이유
제네릭을 사용할 수 없는 경우
제네릭 메서드란?
제네릭 타입 제한하기 (Bounded Type Parameter)

서론

사실 제네릭을 공부할 생각은 없었다. 이미 잘 쓰고있고 잘 이해하고 있다고 착각(?) 했기 때문이다. 자바로 개발을 하면서 JDK 소스를 볼일이 한번씩 생기는데, 자바를 개발한 사람은 이걸 어떻게 만들었나 훑어보다가 ‘봐도 모르겠네~’ 하고 넘어가는게 습관처럼 되어 버렸다. 그러다가 JPA 를 사용하면서 Optional 을 사용하게 됐고, Optional 을 사용하다보니 람다와 스트림 API 를 사용하게 됐고, 그러다가 만난녀석이

public void ifPresent(Consumer<? super T> consumer) {
    if (value != null)
        consumer.accept(value);
}

이놈이다.

Consumer<? super T> 는 대체 뭐하는 놈일까 궁금해졌다. 항상 그냥 지나치다가 이번에는 좀 짚고 넘어가야겠다 싶어서 다시 공부해보았다. 이번 포스팅에서는 저놈이 뭐하는 놈인지 설명하지는 않고, 저놈이 뭐 하는 놈인지 이해하기 위한 배경지식을 쌓는 포스팅이다.

제네릭이란

JDK1.5 에 처음 도입되었다.

Generics add stability to your code by making more of your bugs detectable at compile time. – Oracle Javadoc
제네릭(Generic)은 클래스 내부에서 사용할 데이터 타입을 외부에서 지정하는 기법을 의미한다. – 생활코딩
지네릭스는 다양한 타입의 객체들을 다루는 메서드나 컬렉션 클래스에 컴파일 시의 타입체크를 해주는 기능이다. – 자바의 정석

대충 읽어보면 뭔가 타입에 대한 정보를 동적으로 넘겨줄 수 있고, 런타임시에 발생할 수 있는 오류를 컴파일 타임에 발견할 수 있도록 하는 것 같다. 일단 이정도 이해하고 넘어가고 예제를 보면서 하나씩 뜯어보자.

제네릭을 사용하지 않는 경우 문제점

자바에서 자주 사용하게 되는 ArrayList 를 모방하여, 아주 간단하고 제네릭을 사용하지 않는 SimpleArrayList 를 만들어보자. 제네릭을 사용하지 않아도 여러가지 타입을 받아 저장할 수 있는 ArrayList 를 만들 수 있다. 모든 클래스는 Object 클래스를 상속받기 때문에 Object 타입으로 받으면 그 어떤 타입이라도 받을 수 있기 때문이다.

제네릭을 사용하지 않고도 어떤 타입이든 5개 요소를 담을 수 있는 ArrayList 를 만들면 아래와 같다.

(설명의 편의를 위해 capacity 가 다 찼을 때 array 를 resizing 하거나 하는 로직은 모두 빼고 보도록 하자. 혹시 궁금하다면… 여기와 여기를 참고하기 바란다.)

public class SimpleArrayList {
    private int size;
    private Object[] elementData = new Object[5];

    public void add(Object value) {
        elementData[size++] = value;
    }

    public Object get(int idx) {
        return elementData[idx];
    }
}

이제 이걸 사용해보자.

public class SimpleArrayListTest {
    public static void main(String[] args) {
        SimpleArrayList list = new SimpleArrayList();

        list.add(50);
        list.add(100);

        Integer value1 = (Integer) list.get(0);
        Integer value2 = (Integer) list.get(1);

        System.out.println(value1 + value2);
    }
}

컴파일도 잘 되고 잘 동작하는 것을 확인할 수 있다.

add() 메소드는 파라미터로 Object 를 받기 때문에 어떤 데이터타입도 모두 받을 수 있다. 그러므로 list.get() 부분에서 형변환만 잘 시켜주면 어떤 데이터 타입이든 저장할 수 있다. add(50) 에 들어가게될 50이 스트링으로 들어가게 됐다고 가정해보면 코드는 아래와 같이 될 것이다.

public class SimpleArrayListTest {
    public static void main(String[] args) {
        SimpleArrayList list = new SimpleArrayList();

        list.add("50");  // 달라진부분
        list.add("100"); // 달라진부분

        Integer value1 = (Integer) list.get(0);
        Integer value2 = (Integer) list.get(1);

        System.out.println(value1 + value2);
    }
}

add() 메서드는 Object 타입은 모두 받을 수 있으므로 String, Integer 모두 인자로 줄 수 있다. get() 메서드도 Object 타입을 반환하기 때문에 Integer value1 = (Integer) list.get(0); 이라는 코드에는 문법적으로 아무런 문제가 없다.

실제로도 컴파일이 잘 되는데, 실행하면 런타임에 아래와 같은 오류가 발생하게 된다.

Exception in thread "main" java.lang.ClassCastException:
    java.lang.String cannot be cast to java.lang.Integer
    at com.example.java.generics.basic.SimpleArrayListTest.main(SimpleArrayListTest.java:11)

잘못된 타입캐스팅이 이루어졌다는 오류메시지이다. String 을 넣어놓고서 Integer 로 형변환했기 때문이다.

(제네릭 없는 자바를 사용해보지는 않았지만) 위와같은 방식으로 사용하는 경우, 어떤 타입으로 형변환 할 수 있는지 조차 모호한 경우도 많기 때문에 잠재적인 오류를 가지고 있는 매우 좋지 않은 방식이다.

하지만 컴파일 시점에서는 어떤 오류도 발생하지 않는다는 것이 문제다!

이런 문제를 해결하기 위해 Integer 타입을 가질 수 있는 SimpleArrayList 를 만들고, String 타입을 가질 수 있는 SimpleArrayList 를 만들 수 있다.

SimpleArrayListForInteger.java

public class SimpleArrayListForInteger {
    private int size;
    private int[] elementData = new int[5];

    public void add(int value) {
        elementData[size++] = value;
    }

    public int get(int idx) {
        return elementData[idx];
    }
}

SimpleArrayListForString.java

public class SimpleArrayListForString {
    private int size;
    private String[] elementData = new String[5];

    public void add(String value) {
        elementData[size++] = value;
    }

    public String get(int idx) {
        return elementData[idx];
    }
}

코드의 중복이 생기기 시작한다. 같은 역할을 하는 메소드 add(), get() 이지만 두 군데에 생긴다. 메서드 파라미터 타입과 반환타입이 서로 달라서 인터페이스나 상속을 통해 해결할 수도 없다. 아니면 SimpleArrayList 생성시 변수명을 intList, stringList 처럼 변수명을 다르게 해서 표현할 수도 있을 것 같지만 그래도 좋은 해결방법은 아닌 것 같다.

제네릭을 사용해서 문제해결

GenericArrayList.java

public class GenericArrayList<T> {

    private Object[] elementData = new Object[5];
    private int size;

    public void add(T value) {
        elementData[size++] = value;
    }

    public T get(int idx) {
        return (T) elementData[idx];
    }
}

<T> 로 표현한 것이 제네릭이다. GenericArrayList 는 객체를 생성할때 타입을 지정하면, 생성되는 오브젝트 안에서는 T 의 위치에 지정한 타입이 대체되어서 들어가는 것 처럼 컴파일러가 인식한다. 좀 더 정확하게 말하면, Raw 타입 으로 사용하는데 컴파일러에 의해 필요한 곳에 형변환 코드가 추가된다. (List<String> 을 List 로만 쓰는 것이 Raw 타입으로 사용하는 것이다)

사용은 아래처럼 할 수 있다. 형변환이 필요없다는 것, 지정한 타입과 다른 타입의 참조변수를 선언하면 컴파일타임에 오류가 발생한다는 것이 중요포인트다.

Test.java

class Test {
    public static void main(String[] args) {
        GenericArrayList<Integer> intList = new GenericArrayList<>();
        intList.add(1);
        intList.add(2);

        int intValue1 = intList.get(0); // 형변환이 필요없다
        int intValue2 = intList.get(1); // 형변환이 필요없다

        // String strValue = intList.get(0); // 컴파일에러
    }
}

위 Test.java 파일을 컴파일하고, 컴파일한 Test.class 파일을 역컴파일하면 아래와 같은 결과를 볼 수 있다.

디컴파일 한 결과 (Test.java -> Test.class -> decompile)

class Test {
    Test() {
    }

    public static void main(String[] var0) {
        GenericArrayList var1 = new GenericArrayList(); // 제네릭이 사라졌다
        var1.add(1);
        var1.add(2);
        int var2 = (Integer)var1.get(0); // 형변환이 추가되었다
        int var3 = (Integer)var1.get(1); // 형변환이 추가되었다
    }
}

GenericArrayList<Integer> 로 생성했던 타입파라미터가 사라지고, Raw 타입으로만 사용하는데, 값을 꺼내 쓰는 곳에 형변환 코드가 추가되었다. 제네릭을 사용하면 컴파일러가 형변환을 알아서 진행한다는 것을 확인했다.

한정적 타입 매개변수 (Bounded Type Parameter)

제네릭으로 사용될 타입 파라미터의 범위를 제한할 수 있는 방법이 있다.

위에서 만든 GenericArrayList 가 Number 의 서브클래스만 타입으로 가지도록 하고 싶은 경우 아래와 같이 제네릭의 타입을 제한할 수 있다. (인터페이스나 클래스나 추상클래스나 모두 extends 를 사용한다)

public class GenericArrayList<T extends Number>

위와 같이 정의했다면 GenericArrayList 에는 String 을 담을 수 없다.

Number 의 상위클래스만 타입으로 가지도록 하고 싶은 경우 (적절한 예시는 아니지만) 아래와 같이 제네릭의 타입을 제한할 수 있다.

public class GenericArrayList<T super Number>

바운디드 타입 파라미터가 사용되는 가장 흔한 예시는 Comparable 을 적용하는 경우다. T extends Comparable<T> 와 같이 정의하면 Comparable 인터페이스의 서브클래스들만 타입으로 사용하겠다는 것이다. Comparable 인터페이스를 구현하기 위해서는 compareTo() 메소드를 반드시 정의해야하기 때문에 Comparable 인터페이스를 구현한 클래스들은 비교가 가능한 타입이 된다.

비교하는 로직이 들어간 클래스에는 비교가 가능한 타입들을 다루는 것이 맞을 것이다. 이를 강제하도록 할 수 있는게 바운디드 타입 파라미터이다.

제네릭을 사용할 수 없는 경우

GenericArrayList 를 정의할 때, 다른 부분에는 모두 T 를 사용했는데, 배열을 생성하는 부분에서는 T 를 사용하지 않고 Object 를 사용했고 get() 호출시 T 타입으로 형변환 하는 코드를 삽입했다.

GenericArrayList 가 가지는 elementData 도 new T[5] 와 같이 생성하면 get() 메서드에서 (T) 로 형변환 하는 작업을 안해도 될텐데 왜 한걸까?

그 이유는 new 연산자 때문이다. new 연산자는 heap 영역에 충분한 공간이 있는지 확인한 후 메모리를 확보하는 역할을 한다. 충분한 공간이 있는지 확인하려면 타입을 알아야한다. 그런데 컴파일 시점에 타입 T 가 무엇인지 알 수 없기 때문에 new T[5] 와 같이 제네릭으로 배열을 생성할 수는 없다.

static 변수에도 제네릭을 사용할 수 없다. static 변수는 인스턴스에 종속되지 않는 클래스변수로써 모든 인스턴스가 공통된 저장공간을 공유하게 되는 변수이다.

static 변수에 제네릭을 사용하려면, GenericArrayList<Integer> 에서는 Integer 타입으로, GenericArrayList<String> 에서는 String 타입으로 사용될 수 있어야 하는데 하나의 공유변수가, 생성되는 인스턴스에 따라 타입이 바뀐다는 개념 자체가 말이 안되는 것이다. 그래서 static 변수에는 제네릭을 사용할 수 없다.

하지만, (아래에서 살펴보겠지만) static 메서드에는 제네릭을 사용할 수 있다.

제네릭 메서드

static 메서드에는 제네릭을 사용할 수 있다고 했는데 왜 그런 것일까? 이 질문에 대답하기 전에 제네릭 메서드가 무엇인지 먼저 살펴보자.

제네릭 메서드란

제네릭 메서드를 정의할때는 리턴타입이 무엇인지와는 상관없이 내가 제네릭 메서드라는 것을 컴파일러에게 알려줘야한다. 그러기 위해서 리턴타입을 정의하기 전에 제네릭 타입에 대한 정의를 반드시 적어야 한다.

그리고 중요한 점이 제네릭 클래스가 아닌 일반 클래스 내부에도 제네릭 메서드를 정의할 수 있다. 그 말은, 클래스에 지정된 타입 파라미터와 제네릭 메서드에 정의된 타입 파라미터는 상관이 없다는 것이다. 즉, 제네릭 클래스에 <T> 를 사용하고, 같은 클래스의 제네릭 메서드에도 <T> 로 같은 이름을 가진 타입파라미터를 사용하더라도 둘은 전혀 상관이 없다는 것을 의미한다.

static 메서드 with 제네릭

바로 위에서, static 변수에는 제네릭을 사용할 수 없지만 static 메서드에는 제네릭을 사용할 수 있다고 했는데 왜 그런 것일까?

앞서 말한 것 처럼 static 변수의 경우에 제네릭을 사용하면 여러 인스턴스에서 어떤 타입으로 공유되어야 할지 지정할 수가 없어서 사용할 수 없다. static 변수는 값 자체가 공유되기 때문이다. 값 자체가 공유되려면 타입에 대한 정보도 있어야 한다.

하지만, static 메서드의 경우 메서드의 틀만 공유된다고 생각하면 된다. 그리고 그 틀 안에서 지역변수처럼 타입 파라미터가 다양하게 오가는 형태로 사용될 수 있는 것이다.

이는 static 메서드가 아닌 인스턴스 메서드의 경우에도 마찬가지다. 클래스에 정의된 타입 파라미터와는 전혀 별개로 제네릭 메서드는 자신만의 타입파라미터를 가진다.

static 메서드 with 제네릭 주의사항

착각하면 안되는 것이, 아래와 같은 static 메서드는 허용되지 않는다. 아래 코드에는 두 가지 오류가 있는데, 첫번째는 param 의 타입인 T 를 알 수 없다는 것이고, 두번째는 T 의 타입을 알 수 없기 때문에 charAt() 메서드 호출이 불가능 하다는 것이다.

public static void printFirstChar(T param) {
    System.out.println(param.charAt(0));
}

허용되지 않는 가장 중요한 이유는 제네릭 메서드가 아니기 때문이다. 리턴 타입 앞에 제네릭에 대한 선언이 없다.

클래스에 표시하는 <T> 는 인스턴스 변수라고 생각하면 된다. 인스턴스가 생성될때마다 지정되는 것이기 때문이다. 그러므로, static 메서드에서 인스턴스 변수로 여겨지는 타입 파라미터를 사용하고 있으므로 컴파일 에러가 발생한다.

static 메서드에서 제네릭을 사용하려면 아래처럼 제네릭 메서드로 정의해야 한다.

public static <T extends CharSequence> void printFirstChar(T param) {
    System.out.println(param.charAt(0));
}

제네릭 메서드 선언시 <T> 만 사용해도 상관없다. 위 예시의 경우 charAt() 메서드를 호출하기 위해서 CharSequence 의 서브타입만 가능하다는 제약을 넣은 것이다.

printFirstChar() 제네릭 메서드를 GenericArrayList 에 정의해 주었다면 호출은 아래와 같이 하면 된다.

GenericArrayList.<String>printFirstChar("YABOONG");

그런데 여기서 “YABOONG” 을 통해 인자의 타입이 String 인 것을 컴파일러가 추론할 수 있으므로 <String> 은 생략가능하다. 대부분의 경우 타입추론이 가능하므로 아래와 같이 타입은 생략하고 호출할 수 있다.

GenericArrayList.printFirstChar("YABOONG");

TIP

printFirstChar(T param) 에서 param 변수의 타입은 T 로 아직 지정되지 않았음에도 param.charAt(0) 처럼 charAt() 메서드 호출이 가능한 이유는 <T extends CharSequence> 를 통해 CharSequence 인터페이스를 하위 클래스 타입만 받도록 제한했기 때문이다. CharSequence 인터페이스의 하위 클래스 타입이 되려면 charAt() 을 포함하여 CharSequence 에 정의된 메서드들을 반드시 구현해야 한다.

요약

제네릭을 사용하는 이유는 아래와 같다.

형변환이 필요없고, 타입안정성이 보장된다.
코드의 재사용성이 높아진다.

참고한 자료

스프링 - Spring Cloud Config 예제

Sun, 25 Nov 2018 00:00:00 +0000

개요

Spring Cloud Config
스프링 설정파일을 외부로 분리할 수 있는 스프링 클라우드 Config 에 대한 핸즈온 (Hands-On) 예제

Spring Cloud Config 란

아래는 Spring Cloud Config 에 들어가면 나오는 설명 요약이다.

Spring Cloud Config 는 분산 시스템에서 설정파일을 외부로 분리하는 것을 지원한다.
Spring Cloud Config 를 사용하면 외부 속성을 중앙에서 관리할 수 있다.
스프링 애플리케이션은 물론, 다양한 애플리케이션에서 동일하게 설정파일을 사용할 수 있다.
설정파일 구성의 기본은 git 을 사용한다.

필자의 수준으로 요약하면 스프링 프로젝트의 설정파일을 외부로 분리하여 다양한 환경에서 사용하도록 할 수 있고, 설정이 변경되었을 때 애플리케이션의 재배포 없이 적용가능하다 정도로 받아들였다.

MSA 에서는 수많은 애플리케이션들이 생겨나게 되는데, 수많은 애플리케이션들의 설정파일을 한곳에서 중앙집중관리를 할 수 있도록 해주는 것이 장점인 것 같다.

TL;DR (Too Long; Didn’t Read)

바로 예제 돌려보고 시작하길 원하는 사람은 아래 Repository 를 참고하면 된다.

잡생각

MSA(Micro Service Architecture: 마이크로 서비스 아키텍처) 
공부중에 Spring Cloud Netflix 와 Spring Cloud Config  알게됨

MSA 뭐 있나? 그냥 쪼개면 되는거아냐? 하고 무식한 생각을 했던 자신에 대한 반성과 함께...
참 무지하다 갈길이 멀다... 
Spring Cloud Netflix 도 하나씩 사용해봐야겠다.

애플리케이션을 잘게 쪼개면서 생기는 다양한 문제들 을 해결하기 위한 도구로
(로그관리, 모니터링, 부하분산, 써킷브레이킹, 상태파악 등등 갈길이 멀다..) 
자바진영에서는 Spring Cloud Netflix 를 많이 사용하는 것 같다.

MSA 를 공부하다보니... 최근(?)에 화두가 되는 
* CI / CD / Docker / Kubernetes
* ELK(ElasticSearch Logstash Kibana)
* TDD
* Spring Cloud / Spring Boot 
등등 다양한 기술들이 왜 그렇게 화두가 되는지 이제 아주 아주 아~~주 조금 알 것 같다. 

살펴볼 내용

총 3가지를 만들 것이다.

Github Repository 에 설정파일 저장
Spring Cloud Config Server (이하 Config Server) - 설정파일 배달부
Spring Cloud Config Client (이하 Config Client) - 설정파일 사용자

클라이언트 앱이 기동할 때 사용하는 설정파일은 Config Server 에서 돌려준 설정파일을 사용할 것인데, Config Server 에서 돌려줄 설정파일이 Github Repository 에 세팅해 둔 설정파일이 되도록 할 것이다.

1. Github Repository 에 YAML 파일 저장

Github Repository 를 하나 파고 아래 두 파일을 만들어 저장한다. YAML 파일이름의 경우 ${ApplicationName}-${EnvironmentName}.yml 로 해주는 것이 디폴트이다. 왜 그렇게 하는지는 아래 3. Spring Cloud Config Client 세팅에서 설명한다.

yaboong-dev.yml

who:
  am:
    i: dev-yaboong

yaboong-live.yml

who:
  am:
    i: live-yaboong

2. Spring Cloud Config Server

2-1. Dependency 추가

클라이언트에게 설정파일에 대한 요청을 반환해 때, 앞서 Github Repository 에 만들어 둔 설정파일을 반환하는 서버를 만들 차례다. 스프링 부트 프로젝트를 하나 생성하고 dependency 를 아래와 같이 설정해준다.

dependencies {
    implementation('org.springframework.cloud:spring-cloud-config-server')
}

2-2. Spring Cloud Config Server 설정파일 설정

src/main/resources/application.yml 파일을 아래와 같이 설정해준다. 스프링 부트 프로젝트를 생성하면 자동으로 생성되는 application.properties 파일을 사용해도 되지만 YAML 파일이 타이핑을 덜 해도 돼서 좋다.

spring:
  cloud:
    config:
      server:
        git:
          uri: https://github.com/yaboong/spring-cloud-config-repository

uri 에는 1번 단계에서 생성한 Github Repository 의 uri 를 적어준다. 환경변수로 SPRING_PROFILES_ACTIVE 를 별도 지정하지 않았다면 디폴트 설정파일인 application.yml 을 읽어 실행하게 된다.

(참고로 SPRING_PROFILES_ACTIVE 를 test 로 지정하고 실행하면 스프링 부트 앱 기동시 application-test.yml 파일을 찾아 실행한다)

2-3. YourApplication.java

스프링 부트 프로젝트를 생성하면 자동 생성되는 main() 함수가 담긴 클래스에 아래와 같이 @EnableConfigServer 어노테이션을 추가해준다.

@SpringBootApplication
@EnableConfigServer
public class ConfigServerApplication {

    public static void main(String[] args) {
        SpringApplication.run(ConfigServerApplication.class, args);
    }
}

2-4. 실행

실행로그 중 Github 에 만들어둔 yaboong-dev.yml, yaboong-live.yml 파일을 가져와서 어딘가에 Add 해 두는 것을 볼 수 있다.

Adding property source: file:/var/folders/mz/7nk42g591rzd1v3x18ln5jpm0000gn/T/config-repo-8358493613395248430/yaboong-dev.yml
Adding property source: file:/var/folders/mz/7nk42g591rzd1v3x18ln5jpm0000gn/T/config-repo-8358493613395248430/yaboong-live.yml

2-5. 설정파일 가져오기

yaboong-dev.yml

$ curl -X GET http://localhost:8080/yaboong/dev

{
  "name": "yaboong",
  "profiles": [
    "dev"
  ],
  "label": null,
  "version": "ad12fd3da589a62c58c095b4c84a87345e8972e9",
  "state": null,
  "propertySources": [
    {
      "name": "https://github.com/yaboong/spring-cloud-config-repository/yaboong-dev.yml",
      "source": {
        "who.am.i": "dev-yaboong"
      }
    }
  ]
}

yaboong-live.yml

$ curl -X GET http://localhost:8080/yaboong/live

{
  "name": "yaboong",
  "profiles": [
    "live"
  ],
  "label": null,
  "version": "4d0b729cd29631d27f4ef68146c39beddd21572d",
  "state": null,
  "propertySources": [
    {
      "name": "https://github.com/yaboong/spring-cloud-config-repository/yaboong-live.yml",
      "source": {
        "who.am.i": "live-yaboong"
      }
    }
  ]
}

JSON 형태로 반환하기 때문에 다른 프레임워크나 언어로 된 애플리케이션에서도 가져다 쓸 수 있다. 이것으로 Github Repository 의 설정파일을 반환해주는 서버설정은 끝이다.

3. Spring Cloud Config Client

이제 설정파일을 Config Server 로부터 받아와서 애플리케이션을 빌드할 클라이언트를 만들차례다. Config Server 가 8080 포트를 사용중이므로 Config Client 는 8081 포트를 사용하도록 설정하겠다.

3-1. Dependency 추가

dependencies {
    implementation('org.springframework.boot:spring-boot-starter-web')
    implementation('org.springframework.cloud:spring-cloud-starter-config')
    implementation('org.springframework.boot:spring-boot-starter-actuator')
}

actuator 를 반드시 추가해주어야 한다.

3-2. Spring Cloud Config 클라이언트 설정파일 설정

서버의 경우 application.yml 만 사용했지만, 클라이언트의 경우 application.yml 이 아닌 다른 설정파일을 사용할 것이다. bootstrap.yml 파일의 경우 스프링부트 앱 기동시 application.yml 보다 먼저 로드되므로 src/main/resources/bootstrap.yml 파일의 설정정보를 아래와 같이 수정해준다.

server:
  port: 8081

spring:
  application:
    name: yaboong
  cloud:
    config:
      uri: http://localhost:8080

server.port 값은 8081 에 Config Client 를 띄울것이라는 설정이고, Spring Cloud Config Client 와는 전혀 무관한 설정이다. 그냥 Config Server 가 8080 포트를 사용중이므로 충돌을 피하기 위함이다.

spring.application.name 값은 1번 단계에서 설정파일의 이름을 ${ApplicationName}-${EnvironmentName}.yml 으로 하는 것이 디폴트라고 한 것과 상관있다.

$SPRING_PROFILES_ACTIVE 값을 dev 로 설정한 경우, 위 설정을 바탕으로한다면 http://localhost:8080/yaboong/dev 의 설정을 읽어와 애플리케이션을 실행하게 된다.

spring.application.name 값을 yaboong 이 아닌 yb 로 한다면, http://localhost:8080 에 떠있는 Config Server 가 바라보고 있는 Github Repository 에 yb-dev.yml 파일이 있어야 한다.

3-3. 설정파일을 내용을 동적으로 반영할 컨트롤러 작성

아래와 같이 컨트롤러를 하나 만들어 준다. Github Repository 에 만들어둔 설정파일에서 who.am.i 값을 읽어와 반환하는 Rest Controller 이다.

@RestController
@RefreshScope
public class ConfigClientController {

    @Value("${who.am.i}")
    private String identity;

    @GetMapping("/test")
    public String test() {
        return identity;
    }
}

포인트는 @RefreshScope 어노테이션이다. 이 어노테이션이 붙은 클래스에는 특정행동 수행시 변경된 설정파일의 설정이 애플리케이션의 재배포과정 없이 실시간으로 반영된다.

3-4. 설정파일 변경내용 반영을 위한 설정추가

Github Repository 의 설정파일을 변경하고 Push 하면 바로 설정이 반영되면 좋겠지만 그렇게 되지는 않는다. 직전 단계 (3-3) 에서 특정행동 수행시 라고 했는데, 설정파일이 변경되면 변경사항을 반영하기위해 Config Client 에 POST 요청을 하나 날려줘야 한다.

일단 아래와 같이 application.yml 파일을 설정해두고 애플리케이션을 실행시키고 어떻게 되는지 살펴보자.

management:
  endpoints:
    web:
      exposure:
        include: refresh

위와 같이 설정해두면 http://localhost:8081/actuator/refresh 로 POST 요청을 보내면 설정파일을 새로 읽어들여서 애플리케이션이 재기동된다.

일단 클라이언트앱을 실행시켜보자. 실행시킬 때 SPRING_PROFILES_ACTIVE 값을 live 로 주고 실행시켜보자. Github Repository 에 있는 yaboong-live.yml 설정파일을 읽어와 애플리케이션을 실행하게 될 것이다.

Intellij 에서 실행한다면, 우측상단의 Run 버튼 왼쪽의 YourApplication 을 클릭하고 Edit Configuration 으로 가서 Active profiles 값을 live 로 설정해주면 된다.

CLI 에서 실행한다면, build.gradle 파일을 아래와 같이 추가설정을 해주고 (환경변수로 지정해도 된다)

bootRun {
    systemProperties = System.properties
}

프로젝트 디렉토리로 가서 아래와 같이 실행시켜도 된다.

$ gradle bootRun -Dspring.profiles.active=live

3-5. 실행

실행로그 중 첫 세줄이 중요하다.

Fetching config from server at : http://localhost:8080
Located environment: name=yaboong, profiles=[live], label=null, version=4d0b729cd29631d27f4ef68146c39beddd21572d, state=null
Located property source: CompositePropertySource {name='configService', propertySources=[MapPropertySource {name='configClient'}, MapPropertySource {name='https://github.com/yaboong/spring-cloud-config-repository/yaboong-live.yml'}]}

Config Server 로 떠있는 http://localhost:8080 에서 설정을 가져온다.
가져올때는 http://localhost:8080/yaboong/live 로 요청을 보내 가져왔을 것이다.
실제로 가져온 파일은 https://github.com/yaboong/spring-cloud-config-repository/yaboong-live.yml 이다.

아래와 같이 /test 로 GET 요청을 보내면, Github Repository 에 있는 yaboong-live.yml 파일의 who.am.i 필드값을 반환하는 것을 확인할 수 있다. (좀 더 정확히 말하면 Config Server 에 캐시해둔 yaboong-live.yml 파일이 되겠다)

$ curl -X GET http://localhost:8081/test
live-yaboong

3-6. Github Repository 의 설정파일 변경

yaboong-live.yml 파일의 내용을 변경하고 클라이언트 애플리케이션에 반영되는 것을 보자.

파일 내용을 간단하게 아래와 같이 수정하고 push 한다.

yaboong-live.yml

who:
  am:
    i: live-yaboong, it's working!

이제 클라이언트 애플리케이션의 /actuator/refresh 로 POST 요청을 보내서 변경된 설정파일이 적용되도록 해보자.

$ curl -X POST http://localhost:8081/actuator/refresh

클라이언트 애플리케이션의 실행로그를 보고 있다면, POST 요청을 받자마자 설정파일을 Config Server 로부터 새로 받아와서 애플리케이션이 재시작 되는 것을 볼 수 있다. 변경된 설정의 경우 @RefreshScope 어노테이션이 적용되어 있는 클래스에만 적용된다.

이제 다시 /test 로 요청을 보내서 새로운 설정을 읽어왔는지 확인해보면

$ curl -X GET http://localhost:8081/test
live-yaboong, it's working!

이렇게 Spring Cloud Config 에 대한 헬로월드는 마무리… 신기하당

참고한 자료

디자인패턴 - 프록시 패턴

Wed, 17 Oct 2018 00:00:00 +0000

개요

프록시 패턴에 대해 알아본다.
Coursera 의 디자인패턴 강의 를 기반으로 작성했다.

프록시 패턴

주체가 되는 클래스는 민감한 정보를 가지고 있거나, 인스턴스화 하기에는 resource intensive (자원 집약적인.. 뭔가 무거운 느낌이라고 생각하면 됨) 한 클래스일 수 있다. 프록시 클래스가 Wrapper 의 역할을 함으로써, 클라이언트에서는 프록시 클래스를 통해 간접적으로 주체 클래스를 사용하는 방식이다.

간단하게 말해서, 왕고한테 물어보기 전에 사수한테 먼저 물어보는 방식이다.

짬찌가 클라이언트라면, 짬찌의 맞고참이 프록시고, 최고참이 주체클래스인 셈이다.

프록시가 사용되는 세가지 방법

1. Virtual Proxy

주체 클래스가 리소스 집약적인 경우이다. 예를들어, 주체 클래스가 해상도가 아주 높은 이미지를 처리해야 하는 경우 인스턴스화 할때 많은 메모리를 사용하게 되는데, 이런 이미지들에 동시에 많은 접근이 이루어진다면 시스템에 부하가 많이 가게 될 것이다. 프록시 클래스에서 자잘한 작업들을 처리하고 리소스가 많이 요구되는 작업들이 필요할 때에만 주체 클래스를 사용하도록 구현할 수 있다.

2. Protection Proxy

주체 클래스에 대한 접근을 제어하기 위한 경우이다. 프록시 클래스에서 클라이언트가 주체 클래스에 대한 접근을 허용할지 말지 결정하도록 할 수 있다. 어떤 접근권한을 가지고 있는지에 따라 그에 맞는 주체 클래스의 메소드를 호출하도록 구현할 수 있다.

3. Remote Proxy

프록시 클래스는 로컬에 두고, 주체 클래스는 Remote 로 존재하는 경우이다. Google Docs 같은 것이 대표적인 예시이다. 브라우저는 브라우저대로 필요한 자원을 로컬에 가지고 있고, 또다른 일부 자원은 Google 서버에 있는 형태이다.

프록시 패턴 Overview

Proxy and Real Subject

위 그림과 같이 프록시 클래스는 주체 클래스를 감싸면서 클라이언트의 요청을 주체 클래스에게 위임하거나 리다이렉트한다. 프록시 클래스는 주체 클래스 경량화된 버전으로 사용되기 때문에 항상 모든 요청을 위임하는 것은 아니고, 보다 실질적인 (or 독립적인) 요청들을 주체 클래스에 위임하는 것이다.

주체 클래스에게 요청을 위임하기 위해서 프록시는 주체 클래스와 같은 인터페이스를 구현함으로써 Polymorphism (다형성) 을 가지게 된다. 즉, 클라이언트에서는 프록시와 주체 클래스의 인터페이스 타입으로 접근하여 사용할 수 있게 된다.

프록시 패턴 사용예제

«Scenario»

글로벌 유통 및 창고를 갖춘 커머스를 운영한다고 가정하자. 주문을 처리하기 위해서는 주문을 전달할 창고를 지정해야한다. 이때 주문서에 재고가 없는 창고로 주문 전달되지 않도록 어떤 창고에 주문을 보낼지 결정할 방법이 필요하다. 주문의 전체 처리를 적절한 창고로 라우트하는 시스템을 구성하여, 재고가 없는 창고에는 주문을 넣지 않도록 하고 싶다.

이 경우는 Protection Proxy 로써 프록시 패턴이 사용되는 경우라고 할 수 있다. Warehouse(창고) 로 전달되는 요청을 프록시에서 걸러서 보냄으로써 Warehouse 에 처리할 수 없는 요청이 가지 않도록 막을 수 있다.

Proxy and Real Subject

1. IOrder «Interface»

클라이언트 소프트웨어가 시스템과 상호작용할 인터페이스를 정의하는 것이 가장 첫 단계다. 이 인터페이스는 OrderFulfillment, Warehouse 클래스가 구현한다.

public interface IOrder {
    boolean fulfillOrder(Order order);
}

2. Warehouse - 주체클래스

두번째 단계는 주체 클래스를 구현하는 것이다. 이 주체 클래스는 실질적으로 주문을 처리하는 구현 메소드를 가지며, 프록시 클래스에서 주문이 가능한지 확인할때 사용할 메소드를 가지고 있다.

public class Warehouse implements IOrder {
    private Hashtable<Integer, Integer> stock;
    private String address;

    @Override
    public void fulfillOrder(Order order) {
        for (Item item: order.getItemList()) {
            Integer sku = item.getSku();
            this.stock.replace(sku, stock.get(sku) - 1);
            
            /* 포장, 배송 등 기타 작업들이 추가적으로 이루어질 수 있음 */
            
            processOne();
            processTwo();
            processThree();
            
        }
    }

    public int currentInventory(Item item) {
        return stock.getOrDefault(stock.get(item.getSku()), 0);
    }
}

3. OrderFulfillment - 프록시 클래스

마지막으로 프록시 클래스를 구현한다. 프록시 클래스에서는 주문이 가능한지 확인하는 모든 작업이 이루어지며, 주문을 이행할 수 있는 경우에만 주체 클래스에 요청을 위임한다.

public class OrderFulfillment implements IOrder {
    private List<Warehouse> warehouses;

    @Override
    public void fulfillOrder(Order order) {
        for (Item item: order.getItemList()) {
            for (Warehouse warehouse: warehouses) {
                if (warehouse.currentInventory(item) != 0) {
                    warehouse.fulfillOrder();
                }
            }
        }
    }
}

이렇게 프록시 클래스로 인해 주문 유효성 검사, 주문의 이행 두 부분으로 분리할 수 있다. 주체 클래스에서는 유효성 검증 작업을 할 필요가 없으며, 주체 클래스의 각 인스턴스인 창고들에서는 재고가 없을 경우에 대한 처리를 신경쓸 필요가 없다.

정리 & 요약

프록시 클래스가 주체 클래스를 감싸는 것을 통해,

Polymorphism(다형성)을 가지도록 디자인함으로써 클라이언트가 하나의 인터페이스 접근할 수 있으며,
리소스 집약적인 객체가 실제로 필요해질 때까지 라이트한 버전의 프록시 클래스로 전처리 등 필요한 작업을 진행할 수 있고, –Virtual Proxy
클라이언트가 주체 클래스에 접근하는 것에 대한 제한이나 어떤 클라이언트인지에 따라 서로 다른 방식으로 요청이 처리되도록 할 수 있다. –Protection Proxy
또한, 동일한 물리적 또는 가상 공간에 있지 않은 시스템을 로컬에 있는 것 처럼 표현할 수 있다. –Remote Proxy

참고한 자료

[Coursera - University of Alberta] Design Patterns 2.1.8 – Proxy Pattern

YABOONG

Low Wing Airplane Maneuver Tips - Steep Spiral

Intro

Disclaimer

TL;DR

Why the Steep Spiral is So Challenging

1. How much bank is enough?

2. What about the airspeed?

3. Time and Cost

4. Different Perspectives (Left vs. Right Seat)

5. The “Low Wing” Struggle

6. Coriolis Illusion

7. Constantly Shifting Winds

8. Everything Happens So Fast

Airplane Flying Handbook

How Steep is “Steep”?

So, What Are the Exact Numbers?

Reasoning behind Airspeed: 90 KIAS (and why Vg might not be ideal)

Bank Angle Strategy: 45° as the Baseline

Downwind Entry - Wouldn’t Headwind be easier?

The Simulation (X-Plane)

Rule of Thumb (based on GS)

Why Back Pressure Matters

Track Log

Commercial Operations: From Confusion to Clarity - Part 119 & 119.1(e)

Intro

Disclaimer

Opening Thoughts

Case Table

Terms & Definitions

Key Takeaways

Case Table - Break Down

Vary - 14 CFR 119.1(e)

Corporate Jet (Small / Large)

#GRAY AREA

Aircraft Management Company

Charter Company

Airline

Gray Area Cases (Not Mentioned in the Table)

Post-Flight Analysis: Near Engine Failure (RPM Gauge Anomaly)

Intro

About the Flight

⚠️ The Incident

What Went Well (The Good)

Areas for Improvement

1. Navigation

2. Radio Communication

3. Checklist Usage

4. Post Flight

Self Reflection

Final Thoughts

No More Confusion: Departure vs. Upwind Leg in the Traffic Pattern

Intro

TL;DR;

Old Confusing Definition of Upwind and Departure Leg in AIM (Before Update)

AIM Updates (Aug 7th, 2025)

What’s Updated? -> [4-3-2] Airports with an Operating Control Tower

Summary of Updates

Instrument Rating Checkride Oral Cheat Sheet (Quick IR review)

Intro

Qualifications

Human Factors & ADM

Regulations & Documents

Weather Service & Product

Weather Theory

Icing

Instrument & Attitude Flying

IFR rules

IFR Flying Procedures

Navigation

Approach

Airspace & IFR Low Chart

W/B

스프링 카프카 Batch Consumer - 의도치 않은 리스너 호출

개요

TL;DR

사용버전

배경

하고자 했던 것

하고자 했던 것을 하기위해